- Operating system: Windows 10
- SonarLint plugin version: 22.214.171.124810
- Programming language you’re coding in: Java
- Is connected mode used: Connected to SonarQube at version 126.96.36.199159
We have quite a big legacy code base and therefore are focusing on “New code” for our Sonar analysis and metrices.
As activating “on-the-fly” checks turned out to be quite slow we encouraged our teams to use the check in the “Before commit” step of the commit dialog.
But unfortunately, the IDEA plugin checks the whole files that are under modification and not only the modified lines of code (as the analysis in SonarQube does).
With the big legacy classes that we have to deal with (although we are cleaning them up step by step) this distracts the developers from the rule violations they produced with their modifications.
Any help on this problem?
we are indeed considering a new feature in SonarLint for IntelliJ to focus on new issues only - the main goal would be exactly the one you mentioned: kill the noise and avoid distracting developers, so it will be easier for them to avoid new issues being merged into the code base. We’ll probably be looking at ways to do this during 2023, and you can follow this card in our roadmap page.
I would be interested to learn what definition of “New Code” you would prefer to see in SonarLint. Do you think SonarLint should apply the same definition of New Code configured in your SonarQube, or should it be something else, like “since the last commit only”?
As activating “on-the-fly” checks turned out to be quite slow
Do you find the on-the-fly analysis slow only for very large classes? Could you share the approximate number of LOCs that lead to analysis being “too slow”?
Hello @Marco_Comi ,
that’s great news, thanks for your fast answer!
Regarding your questions:
- SonarLint for IntelliJ and “new code” - I guess having a consistent interpretation between Qube and Lint would make more sense. If I push my changes and everything is fine in IDEA’s before commit check I don’t want to receive a notification by SonarQube that something’s wrong.
- A ~7K lines Java class takes ~30 seconds on my machine (~500 findings)
- A ~500 lines Java class takes ~1 second on my machine (16 findings)
Unfortunately we have several classes like the former, although the majority is like the latter.
Maybe you could offer an option for a line threshold (do not scan files automatically that have > X lines)?
Kind regards, Stefan
Hello @StefanR and thanks for the answers!
We’d like to give a closer look at why this is so slow. Would you mind sharing with us a few more information if possible?
- hardware info (CPU, RAM)
- your CLASSPATH
- did you customize your SonarQube quality profile? in this case which rules did you activate or deactivate?
CPU: Intel(R) Core™ i7-10510U CPU @ 1.80GHz 2.30 GHz
RAM: 32,0 GB
OS: Windows 10 Enterprise
Classpath: Which one do you mean? I could send you the Maven dependencies of the project that example class resides in. Or the one of the plugin? How can I see that?
Profile: we did customize it by disabling some rules (all security related ones because we use a different tool for that, and also some rules we don’t like):
(How can I get a report of deactivated rules?)
I will take continue to investigate the performance issue with you.
Your hardware spec looks good.
Can you please:
Enable verbose + analysis logs in the SonarLint log tab
- Clear the logs
- Analyze the 7K file alone (got to the SonarLint → Current file and click on the green “play” button)
You should get a lot of logs, but we are only interested in logs with timings at the moment. Something like:
[Action] 1 file(s) submitted
JavaClasspath initialization (done) | time=3ms
JavaTestClasspath initialization (done) | time=3ms
Analysis time of [uri=file:///home/julien.henry/Projects/XXXXX.java] (1880ms)
Java "Main" source files AST scan (done) | time=1881ms
Done in 1931ms
Can you share those infos here please?