Analysis time for 6.3 not on par with 5.14

SonarQube Server / Community Build
,
1

This is a follow up thread to Expected performance hit with new Java analyzer?

After upgrading SonarJava from 6.2 to 6.3 the time for analysis dropped from about 45 hours to 33 hours; however, it is still not on par with the time it required using version 5.14 (about 3 hours). Inbetween nothing major changed (some rules were activated, some deactivated; there were no spikes in runtime).
The following are the runtimes of the different sensors of the last four analyses:

                                                      6.2        6.2        6.3        6.3
Sensor JavaSquidSensor [java]: ...............	175163028  163599582  121202580  120987414
Load global settings: ........................	      124        130        133        120
Sensor JavaXmlSensor [java]: .................	      225        219        207        232
JavaTestClasspath initialization: ............          1          1          1          2
Load project settings for component key: 'key':        16         14         40         18
Sensor Java CPD Block Indexer: ...............      36028      31286      32324      23926
Sensor Zero Coverage Sensor: .................      12255      10773      11316      11187
Sensor Custom1: ..............................       2685       2763       2748       2744
Load metrics repository: .....................         20         22         24         19
Sensor SurefireSensor [java]: ................          2          3          2          2
Sensor JaCoCo XML Report Importer [jacoco]: ..        104         99         99         99
Java Generated Files AST scan: ...............	                              1          1
Java Test Files AST scan: ....................	   269567     256111     248909     255587
Sensor Custom2: ..............................	     4541       3887       4301       3842
Load plugins index: ..........................	       41         49         50         31
Load active rules: ...........................	      121        128        386        138
Java Main Files AST scan: ....................	174878300  163329044  120943535	 120723901
Load/download plugins: .......................	      253        136         66         46
Load project repositories: ...................       1364        957       1065        940
Load quality profiles: .......................         39         29         40         26
JavaClasspath initialization: ................      13455      12803       9395       7255

Timings (in milliseconds) are from the scanner log files, if necessary I can provide the full log file. I do not have logs for 5.14 anymore.

3

Hello @oliver,

Thanks for sharing your feedback. In a way, I’m glad that at least our latest release improved quite a lot already the total time (from 45 to 33h is not negligible), even if of course it does not at all got back to 5.14 times.

We don’t have a lot of huge projects on our side to tests such long-time analysis time, so it’s a bit surprising, as the biggest projects we analyze for our benchmark went back to normal.

  • Could you share a bit more about your analysis configuration?
    Maybe the machine used for the analysis is not powerful enough;

  • Is there some particularities or specificities on your projects which you could disclose?

    • Project has numerous generated files,
    • project has enormous files,
    • Which java version it relies on
    • Which scanner do you use (maven/gradle/sonarScanner),
    • etc.

    Maybe some files could be excluded from project!

  • Would you mind testing another beta-version of the Java analyzer on your project, on which we would display times for each part?
    i.e parsing, subscription-based rules, visitor-based rules, symbolic-execution based rules, etc.

  • Could you try to disable the rules which are based on Symbolic Execution, which are usually taking a lot of effort?
    We identified some hotspots on them which could be one of the reasons.
    Here is the list of the rules:

EDIT: sorry for the broken links on rules, fixed.

2 Likes
6

Hi @Michael,

sorry for the long delay, it took some time to collect data.

First: The anlysis consistently takes about 36 hours, which is already a huge benefit.

Our projects hav around 2.9 million loc combined, for testing purposes I used only parts of it. The subset hat about 1.8 million loc, ~25k classes in ~23k files. The projects are build with Java 8, we are using SonarScanner on Jenkins. All generated files are excluded from analysis, but are available as binaries. There are some large classes (> 3000 loc) on which a huge amount of classes depend on, but even excluding those from analysis does not affect the execution time.
Currently the project layout for the scanner is as follows:

root\
  project1\
    src\
    bin\
  project2\
   src\
   bin\
  ...

The scanner is configured to take all src and bin as input:

sonar.sources=root
sonar.binaries=**/bin

We are aware that such a configuration might be problematic, but we aren’t using maven oder gradle and we have so many projects that it is not feasible to configure a multi-module project (I’m not sure if these are event supported anymore).
The hardware shouldn’t be a problem; execution time spiked as soon as we switched to SonarJava 6.0

Analysis of this subset takes around 10 - 12 hours with around 200 rules and the same amount of time with only one rule (java:S3599).

I can give a beta version of the scanner a try.

Thanks for your time.