Soon as I disable the plugin, my system become quiet and everything seems to be working fine.
Thanks a lot for your feedback.
If you look at the background processes in Windows, you should see 2 processes started by SonarLint:
- a Java process
- a nodejs process
You can see on my side that memory consumption is acceptable, after analyzing a few JS/TS files.
Would you be able to determine which one of the two processes is consuming CPU/memory?
Does the CPU/memory consumption occurs immediately after starting VSCode and opening a single file, or only after some time of work (opening multiple files, changing code). I would like to understand if the problem is specific to your project or hardware, or if we have a memory leak.
Another thing you can try is to enable verbose and analysis logs in VSCode settings:
Then open and clear content of the SonarLint output:
And finally open a source file you know will make your CPU burn. Watch log output, trying to determine at which step it is taking time.
I’m using PHP and I see so many PHP CLI processes and they are too many. I have re-enabled the plugin to get the screenshot. I will post in sometime.
SonarLint has its own PHP parser, and doesn’t call the PHP CLI. Are you sure your issues are not caused by another extension?
For now I dont see cpu issue but it consumes too much memory:
OK, so this is the language server that is consuming memory. Let’s try to dig a little bit more. Would you mind capturing a heap dump of the Java process when the memory consumption is high? There are multiple options (see https://www.baeldung.com/java-heap-dump-capture) and I recommend using the graphical tool JVisualVM.
The captured file might be big, but you can share it with me on a cloud hosting service.
Java works by allocating memory aggressively, especially when your system has a lot like you. It will only garbage collect and returns to the OS when needed, to avoid costly memory operations. So the fact the OS shows that the process is taking 3Gb is not totally anormal (even if I can’t reproduce). It may simply means that it needed that much during a short moment, for example to analyze a big file, and has not yet released it.
In JVisualVM, you will see the “true” heap size. There is a button to force the garbage collection to occurs. If the heap size goes down dramatically, then it is “fine” (I can give you tips if you want to force the heap to stay under a given max value). If the memory stays high in JVisualVM even after forcing the GC, then it means we possibly have a memory leak, and the heap dump will help to find it.