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.
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.
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).
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.