Deprecated build wrapper analysis mode is much faster than the compilation database mode

SonarQube Server / Community Build
, ,
1

  • which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)

    • SonarQube: v10.6 (92116)
    • Scanner: 5.0.1.3006-linux
    • GitHub Actions: sonarsource/sonarqube-github-c-cpp@v1

  • how is SonarQube deployed:
    zip

  • what are you trying to achieve
    Since the build wrapper output is deprecated as of 10.6, I am trying to migrate my GitHub Actions workflow to the compilation database output format.

  • what have you tried so far to achieve this

    1. Changed the Scanner arguments from:
    --define sonar.cfamily.build-wrapper-output="${{ env.BUILD_WRAPPER_OUT_DIR }}"

    to:

    --define sonar.cfamily.compile-commands="${{ env.BUILD_WRAPPER_OUT_DIR }}/compile_commands.json"
    1. Made a couple of scans to compare performance:
    • Using build wrapper output: ~4 minutes per scan
    • Using compile commands: ~12 minutes per scan

Although I understand that the scan can be slightly slower for better accuracy, the deprecated method is significantly (and consistently) faster.

Logs
build-wrapper-output

INFO: Analysis done in: 152912ms
INFO: 417/418 files marked as unchanged
INFO: Analysis cache: 132/190 hits, 2411238 bytes
INFO: SE: 190 out of 190
INFO: Performance statistics per analysis stage (Total, Average, Percentage) across 190 compilation units:
annotationStage: 5599ms, 29ms, 0.5%
astRulesStage: 86165ms, 453ms, 7.63%
configStage: 1095ms, 5ms, 0.1%
parsingStage: 52412ms, 275ms, 4.64%
symbolicExecutionStage: 983346ms, 5175ms, 87.13%
INFO: PCH: unique=20 use=139 (forceInclude=139,throughHeader=0,firstInclude=0) out of 190 (forceInclude=140,throughHeader=0)
INFO: Z3 refutation rate: 0 out of 272
INFO: Percentage of files indexed with CFamily languages: 46.86% (C: 418, C++: 0, ObjC: 0, Indexed: 892)
INFO: C and C++ analysis quality score: 100/100
INFO: Analysis measures statistics:
100% of classes were parsed successfully (0 out of 0 have parsing errors)
100% of functions were parsed successfully (0 out of 4397 have parsing errors)
100% of statements were parsed successfully (0 out of 140351 have parsing errors)
100% of the project includes directives were resolved (0 out of 3606 were not resolved)
0 external includes directives were not resolved
0 modules imports were not resolved
INFO: 190 compilation units analyzed
At the end of analysis setup: 117MB, 117MB
At the end of lexical analysis: 202MB, 262MB
At the end of analysis requests computation: 118MB, 240MB
At the end of the analysis: 192MB, 274MB
At the end of the sensor: 135MB , 232MB
Note that these values may not be accurate due to garbage collection; they should only be used to detect significant outliers.
INFO: Sensor CFamily [cpp] (done) | time=157088ms
INFO: Sensor TextAndSecretsSensor [text]
INFO: Sensor TextAndSecretsSensor is restricted to changed files only
INFO: Available processors: 64
INFO: Using 64 threads for analysis.

compile-commands

INFO: Analysis done in: 682653ms
INFO: 400/418 files marked as unchanged
INFO: Analysis cache: 0/190 hits, 2379300 bytes
INFO: SE: 190 out of 190
INFO: Performance statistics per analysis stage (Total, Average, Percentage) across 190 compilation units:
annotationStage: 6711ms, 35ms, 0.54%
astRulesStage: 97983ms, 515ms, 7.82%
configStage: 945ms, 4ms, 0.08%
parsingStage: 63753ms, 335ms, 5.09%
symbolicExecutionStage: 1083325ms, 5701ms, 86.48%
INFO: PCH: unique=8 use=139 (forceInclude=139,throughHeader=0,firstInclude=0) out of 190 (forceInclude=140,throughHeader=0)
INFO: Z3 refutation rate: 0 out of 275
INFO: Percentage of files indexed with CFamily languages: 46.86% (C: 418, C++: 0, ObjC: 0, Indexed: 892)
INFO: C and C++ analysis quality score: 100/100
INFO: Analysis measures statistics:
100% of classes were parsed successfully (0 out of 0 have parsing errors)
100% of functions were parsed successfully (0 out of 4416 have parsing errors)
100% of statements were parsed successfully (0 out of 141565 have parsing errors)
100% of the project includes directives were resolved (0 out of 3610 were not resolved)
0 external includes directives were not resolved
0 modules imports were not resolved
INFO: 190 compilation units analyzed
At the end of analysis setup: 99MB, 99MB
At the end of lexical analysis: 127MB, 190MB
At the end of analysis requests computation: 156MB, 285MB
At the end of the analysis: 140MB, 301MB
At the end of the sensor: 228MB , 228MB
Note that these values may not be accurate due to garbage collection; they should only be used to detect significant outliers.
INFO: Sensor CFamily [cpp] (done) | time=686307ms
INFO: Sensor TextAndSecretsSensor [text]
INFO: Sensor TextAndSecretsSensor is restricted to changed files only
INFO: Available processors: 64
INFO: Using 64 threads for analysis.

Questions:

  • Is it expected for the compilation database mode to be slower than the (deprecated) build wrapper mode?
  • If I use compilation database mode, do I need to change any properties related to the analysis cache or parallel code scan?

Thank you!

2

Hey there.

You have significantly more analysis cache hits in the build wrapper run than the compilation database.

If you run the compilation database again, is the time constant or do you get a faster analysis / more cache hits?

2 Likes
3

If you run the compilation database again, is the time constant or do you get a faster analysis / more cache hits?

When I rerun it, it is much faster with more cache hits (132/190). It took about 3 minutes to complete (190998ms).
I guess that means there must be a problem on the CI server?

4

I think it just means that either

  • After upgrading to 10.6
  • After switching from build wrapper to compilation database

The cache was invalidated, and you needed to fill it again.

If the rerun is much faster now (like you said), than I think there’s no problem left! Am I misunderstanding?

1 Like
5

Yes, you’re right, I wasn’t thinking clearly! :sweat_smile:
Since we have several runners, I saw this happen again and got confused. However, the time was as expected when it ran on the same runner the second time.
Thank you very much!

1 Like
6

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.