Over 100% cpu usage on any changes

Hello!

I am using v3.4.1 of SonarLint on a M1 2020 MacBook Pro and am experiencing over 100% cpu usage on any changes. It takes roughly 20 seconds for it to update the list of current Problems in vscode. Have you heard of any similar reports on this version?

Hello @sonaruser567 and welcome to the community!

Thank you for your report. This is very important feedback, difficult to investigate though.
First of all I can refer to related community thread. 3.4.1 is the new version that contain some fixes for issues discussed in this thread.

If you are ready to help in investigation, I would suggest to check if you have any orphaned processes. Since you are using new v3.4.1 you shouldn’t, but still.
And also thread dump made when you have 100% of CPU usage would be useful.

Hi Kirill. I am not seeing any orphaned processes when I run ps/ps aux and that previous thread mentions.

Also, here is that thread dump. Let me know if that thread dump is good as this is the first time I’ve generated one.
threaddump.txt (8.2 KB)

Hello Cameron,

I don’t see any activity on the threads appearing in this dump. For each thread you can find the cpu time used and you can see that it does not exceed a few milliseconds.

That said, in some cases SonarLint does start processes that are not Java processes. First thing you could check is if you observe the same problem when the extension is disabled/uninstalled. You could also check which OS process is hogging the CPU, maybe with the activity/system monitor.

What language are you trying to analyze when this happens ? Are you using connected mode ? If yes are you using SonarCloud or SonarQube, and if the latter in which version ?

Thanks

Thanks for letting me know where I should be looking to ensure my logs are the right PID and reflect what I am seeing. That was my attempt at using jstack. I tried jvisualvm and I see a few cpu times in the multi-thousand milliseconds, so I think this attempt was better. The first file was me editing a typescript file where I changed the type to an invalid one (which produces the Problem “Replace this “Number” wrapper object with primitive type “number”. sonarlint (typescript:S1533) [Ln 31, Col 39]”) and the second file is when I changed it back.
threaddump-1650921720152.txt (36.5 KB)
threaddump-1650922018094.txt (42.7 KB)

To answer your questions,

  1. When disabled, the highest any cpu process went to was 36%, which was Electron. I am using VS Code so that may just be that.
  2. The process that is getting into the 100+% range is “node”.
  3. TypeScript. The file type from these thread dumps is tsx
  4. Not using connected mode. Here is another thread dump after a clean install of the extension in VS Code, where I ensured the settings.json file did not have any sonarlint settings.
    threaddump-1650922955286.txt (36.4 KB)

Hi Cameron, thanks for those extra details.

I still don’t see anything off on the Java side. We indeed spawn a background node process for TS analysis so it probably comes from there.

Another round of questions:

  • What is the version of node that you are using ?
  • What is the size of the file you are trying to analyze ?
  • Would you be able to share with us a small reproducer project ?
  • Did you activate a non-default rule or change parameters of a default rule ?

It could be that there is a performance problem on a rule. You could also try to strip differents part of the file to check if it’s caused by a specific construct in the code. I will try to reproduce on my side with a M1

Hi Damien, thanks for letting me know what might be the problem based on those files.

  1. Node version v14.17.0
  2. The size of the file that I was editing is 8,536 bytes.
  3. I will see what I can do on reproducing on a smaller/shareable project.
  4. All SonarLint settings are default, so unchecked, blank fields, and nothing sonarlint within the projects settings.json

I will try your suggestions of stripping the file as well as disabling sonarlint rules to see if anything makes a difference and will let you know.

Hi Cameron,

Any update on this ?

Hi Damien,

I created a new project using
npx create-react-app my-app --template typescript, with only the “Wrapper objects should not be used for primitive types” TypeScript setting on (all others in TypeScript and other languages off).

I also added the following to the App.tsx file in order to break that rule.

  const counter = (num: Number) => {
    return null;
  }

and the result is about 4 seconds for it to trigger the warning when switching between num: Number and num: number.

Here’s a thread dump from it as well, if that is helpful.
threaddump-1652718331686.txt (42.8 KB)