Hello,
We’ve started performance investigations into slow-to-analyze translation units. One of the tools to quickly find the problematic part or even to diagnose a known inefficiency is the time tracing already implemented in LLVM. See how it is used for Clang frontend here.
Yet, the facility is useless for Clang Static Analyzer at the moment, because it relies on instrumentation of the source code. I have implemented some high-level instrumentation delineating
- analysis entry points,
- “analysis steps” - the work items processed by the analyzer
- individual checker callbacks invoked as part of some steps
- issue refutation stage
This is a starter list, and I expect to extend it in the future as we investigate particular cases to cover more and more blind spots.
The instrumentation has proved very helpful when investigating analysis time of some slow TUs, and I think it is a handy tool to have at your disposal useful for many CSA developers.
We would like to upstream it to both give back to the community and to reduce our maintenance burden: the instrumentation, as you might expect, touches quite a few places in the code.
In my experience, running the instrumented analyzer with time-tracing disabled added no significant overhead. I’ve run the analyzer in the configuration we use for our product to analyze 200+ open source projects of various sizes. The analysis time is normally quite variable in our CI – about 5-15% of variation in normal conditions. The instrumented version (with tracing disabled, the default) did not show any performance difference outside of the noise levels.
Here are a couple of exmples of insights such traces enable:
- Here you can spot that a single entry point takes 8.2s to analyze (which is rather long) because
ExprEngine::removeDeadtakes 6 seconds cumulatively.
… Another example was forbidden by discourse as a new-user limitation …
