Sonar analysis step suddenly much (5x) slower on Travis CI

sonarcfamily
cpp

(Jack Lloyd) #1

Sometime in the last week (with no intervening code changes), Sonar has become much slower on Travis CI.

Last week https://travis-ci.org/randombit/botan/jobs/453348154#L4802

INFO: Total time: 4:24.111s
INFO: Final Memory: 68M/792M

Now https://travis-ci.org/randombit/botan/jobs/456501558#L4341

INFO: Total time: 27:49.333s
INFO: Final Memory: 63M/499M

Initially I assumed there had been update to Sonar or perhaps Travis, but it appears the same version of SonarQube plugin, Java, and Linux kernel are being used.

INFO: SonarQube Scanner 3.0.3.778
INFO: Java 1.8.0_151 Oracle Corporation (64-bit)
INFO: Linux 4.4.0-101-generic amd64

Any idea what the problem could be?


(Loïc Joly) #3

Hello Jack,

Last week, we deployed on SonarCloud the version 6.0 of our CFamily plugin. It is based on a brand new engine, and in term of performances, it’s hard to compare it with the previous version. On some projects it is faster, on some projects, it is slower. What we do know though is that on all projects, it is more accurate than the previous one, especially when templates are considered (and it therefore tends to be slower in heavily templated code).

I saw in the logs you published that you also tried to use parallel analysis. Unfortunately, on a Travis CI machine that only has 2 cores, we don’t expect you to see any improvement. This feature just requires more cores to shine.

Currently, analyzing your code take about 3.4 times as long as compiling it. While this is something we would clearly like to improve (and we’ll probably use your project in our future benchmarks), we currently do not consider this as a blocker issue. Please tell us if you disagree.

Thank you,


(Jack Lloyd) #4

Thank you for the reply, I appreciate it.

For how it was being used in this project (run on every commit via CI), Sonar is no longer viable for us as it either exceeds the overall Travis build timeout of 45 minutes, or if it does run successfully, causes the overall CI build (with 18 other builds testing various configurations, cross compile, valgrind, etc) to take 2x as long. For now I have disabled Sonar from our CI, I may switch to running it occasionally on demand by having Sonar only run within a particular branch which is occasionally rebased against master (we already have a similar workflow for this with Coverity).

Thanks again.


(Loïc Joly) #5

Hello again,

I’d just like to add that we ran the analysis of your code, getting similar results, and not seeing any particular issue. We could also confirm that the analysis time scales correctly if you add more cores to perform the analysis (going down from 28 minutes to 8 minutes with 4 threads, for instance), which would be the solution we recommend if the analysis is not fast enough (but that would probably mean moving away from Travis CI).

Another option might be to reduce the scope of analysis, for instance by skipping code in unit tests.