Major performance issues with background scanning

[leinardi]

Major performance issues with background scanning

[paranoidi]

It looks like the plugin is spawning a lot of duplicate processes. When I observe htop in second screen while editing a file it spawns up to 10 identical process for the same file.

It would also be VERY beneficial if the plugin would support using dmypy daemon, which is significantly faster on subsequent executions and uses much less resources. I tried to create a hacky wrapper script to get it running via that but it did not work.

[intgr]

(Initially it was my assumption that the plugin could run mypy on saved files only. That ended up not being true -- if there are unsaved changes to a file, the mypy plugin will write to a temporary file and run mypy with that file)

The plugin integrates with IntelliJ via the LocalInspectionTool API, where IntelliJ calls checkFile() to analyse a given file whenever it wants to, which is subject to some heuristics. This often happens even while typing, with unsaved modifications to the file.

IntelliJ can call checkFile() in parallel on multiple threads -- on different versions of the file. And the mypy plugin currently faithfully tries to spawn a new mypy process every time. With increased load, successive runs are even slower, leading to this pathological behavior.

This is very wasteful on IntelliJ's part, plugins are called to calculate inspections for file versions that will never be seen by the user.

There doesn't seem to be any obvious way to make IntelliJ limit those parallel checkFile() calls, but maybe I'm missing something. I guess we could implement throttling within the mypy plugin itself. I wonder whether other plugin authors have already solved this problem.

(I also noticed that sometimes checkFile() is called multiple times when only one change was made. This can be easily detected via psiFile.getModificationStamp() and we can return cached results in that case.)

[spacemanspiff2007]

@leinardi :
This is is critical information and at least a hint should be in the settings page of the mypy plugin.

[intgr]

After searching the web and digging around in IntelliJ source code, I discovered that there's another API called ExternalAnnotator, which seems like a better fit for this purpose:

The external annotator is expected to be slow and is started after the regular annotator has completed its work.

After migrating to this API and removing the use of Async.asyncResultOf, IntelliJ now cancels any previous background inspection jobs when spawning a new one. Not totally sure how the mechanism works, but the ProcessCanceledException is thrown.

There are some dowsides compared to LocalInspectionTool, however. According to https://consulo.dev/reference_guide/custom_language_support/code_inspections_and_intentions/ LocalInspectionTool adds:

• supports batch analysis of code (through the Analyze | Inspect Code... action)
• the possibility to turn off the inspection (globally or by suppressing them on various levels)
• ability to configure the inspection options.

Anyway the code is still a very dirty proof of concept, but can be found at https://github.com/intgr/mypy-pycharm/pull/1/files

[leinardi]

Hi Simon,
I have retested it to be sure and I can confirm that, if you disable the Mypy inspection from your IDE settings, you should have no performance impact at all since it won't run.
Just open the IDE Settings/Preferences then search for "Inspection", look for "Mypy" and remove the check from the entry "Mypy real-time scan":

[stale]

This issue has been automatically marked as stale because it has not had activity in the last 60 days.

[intgr]

I'm having a try at debugging and fixing this issue.

If anyone already has some pointers for why this occurs or how to fix it, please reply here.