Tips for speeding analysis up?


I’m looking at Clang’s analyzer as a replacement for Split (that we’re currently using) and it really looks nice and promising. However, due to a relatively large code base the analysis takes really a lot of time (about 14 minutes compared to the 1 min for Splint) and it won’t be possible to make the analysis every time a developer compile that code (as we did with Splint).

The analysis provided by Clang is really nice and we can certainly run it every few commits/hours/during the night, however I was looking if there is a way to speed it up (even on cost of bugs found) a bit to also have it at compilation time.

Right know, I made sure it’s compiled as a release (and not debug version) and I also disabled deadstore, malloc and similar checks (I’ve noticed they were a little bit slower than other checks), html reports and I’m running it in the following way:

clang -cc1 -triple i386-pc-linux-gnu -analyze -disable-free -disable-llvm-verifier -analyzer-checker=core -analyzer-output plist -w -mrelocation-model static -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -target-cpu pentium4 -target-linker-version -momit-leaf-frame-pointer -resource-dir …/lib/clang/3.2 -fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem /usr/local/include -internal-isystem …/lib/clang/3.2/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdebug-compilation-dir clang/rx2 -ferror-limit 3 -fmessage-length 115 -mstackrealign -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics

In this way it takes about 10 minutes to finish (still 10 times slower than Splint) that’s still too much to run it every time the code is compiled :confused:

May I ask you if you might have any hints for speeding up the analysis a little bit?

Thank you,



There are several low level options that one could use to speed up the analyzes (disable inter procedural analyzes, tell the analyzer to time out sooner,...). However, we do not recommend them. All of them are going to drop bugs found. The idea is that the current set of defaults is the optimal/recommended balance. The clang static analyzer is targeted at deeper checking - something you would run every day, not after every compile.

Said that, we do have a small set of non-path sensitive checks, which are rather fast - they are similar to compiler warnings, but could include stylistic checks or checks with a higher false positive rate. We do not currently have a mode to only enable those without the path-sensitive checking, but this definitely could be done.


Thank you very much for your kind response J

I’ll try that and see how much bugs we miss by doing so.

Kind regards,