did some tests with the new SonarJava 6.0.1 (build 20589) and i can confirm
Used our most problematic Java legacy project for an initial scan.
Sonarqube 8.1 (build 31237) with SonarJava 6.0.1 (build 20589)
Total time: 305 minutes 41 seconds
Sonarqube 8.1 (build 31237) with SonarJava 5.14 (build 18788)
Total time: 83 minutes 44 seconds
It means it’s even more than 3x times, this is a showstopper even if more issues are found
As this was an initial scan, the git blame took a lot of time.
Are there any investigations going on in that area, found only
A while back we finally switched from SVN to Git.
In doing so, I forgot to replace the SVN plugin by the Git plugin in SonarQube though.
So since then, the VCS integration was not used and the analysis builds needed around 2 hours with a resourcs graph like this:
Now with upgrading SonarQube from 6.5 to 7.5 I of course also added the Git plugin.
Unfortunately now the builds need around 24 - 30 hours (yes, about a day, this is not a typo) with a resource graph like this:
but nothing new.
I don’t think it is caused by SCM. SonarJava 6.X uses a new compiler which allows finding more stuff, but works slower. Read more here:
I don’t claim it’s caused by SCM, this was just a btw question wrt to the jgit <-> git discussion.
It’s only a real problem with the initial scan, as afterwards only the changed
files are blamed.
Seems that switching to Eclipse JDT compiler comes with a huge performance loss.
3x more is too much.
could you please share the logs of your analysis ? so that we can maybe spot which sensor is taking time ?
Thanks for your help.
need to recreate the logs, will create a support ticket and upload the logs.
i’ve created SUPPORT-17326 with all details.
Where can we find the information on this support ticket? SUPPORT-17326?
this is an internal ticket id from Sonarsource Enterprise support.
You may watch this Sonarsource Jira ticket
to see what’s going on with SonarJava performance improvement.