did some tests with the new SonarJava 6.0.1 (build 20589) and i can confirm @pranav-jobvite findings.
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
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.
this is an internal ticket id from Sonarsource Enterprise support.
You may watch this Sonarsource Jira ticket https://jira.sonarsource.com/browse/MMF-1870
to see what’s going on with SonarJava performance improvement.