Just how much is our Clang plugin slowing down builds of LibreOffice? We are constantly adding more and more useful functionality to it, and some of it is well known to be written in a way that is likely performing not too well. But I never dared look at the performance implications too closely, for fear of being disappointed. The build always seemed to go along at more or less the same speed, so who cares for details?
Enter FlameGraph, generating beautiful and easy-to-digest graphs on top of the Linux perf tool’s (or others’) output. So I gathered data about half a minute of CPU activity during the LibreOffice build (randomly picked a time when all the cores were busy compiling .cxx files in the sw module, to keep noise contributed by other processes down to a minimum), and passed it through FlameGraph. And sobering set in:
98.56% of all the time was spent in the clang-3.9 process (i.e., there was almost no noise from unrelated processes). And 19.22% of all time was spent in our plugin. That is, the plugin slows down compilation by about 25%. Quite a number.
Zooming in and breaking this down further per individual plugin, the distribution is
- 1.47% CommaOperator
- 1.04% VCLWidgets
- 0.91% BodyNotInBlock
- 0.79% SalBool
- 0.69% PtrVector
- 0.65% RefCounting
- 0.63% FailedDynCast
- 0.62% ReservedId
- 0.61% Nullptr
- 0.59% RedundantCast
- 0.56% StringConstant
- 0.56% ImplicitBoolConversion
- 0.55% ExternAndNotDefined
- 0.50% PassStuffByRef
- 0.47% DefaultParams
- 0.46% StringConcat
- 0.45% UnusedVariableCheck
- 0.45% SalLogAreas
- 0.45% LiteralToBoolConversion
- 0.44% UnrefFun
- 0.44% ReturnByRef
- 0.43% StaticCall
- 0.43% BadStatics
- 0.42% Override
- 0.41% StaticAnonymous
- 0.41% InlineVisible
- 0.38% SimplifyBool
- 0.38% FpComparison
- 0.37% SfxPoolItem
- 0.35% StaticMethods
- 0.35% PrivateBase
- 0.35% BadVectorInit
- 0.34% DerefNullPtr
- 0.34% CStyleCast
- 0.32% RangeForCopy
- 0.32% LoopVarTooSmall
- 0.29% OnceVar
The recursive nature of RecursiveASTVisitor makes it a bit hard to easily spot each individual plugin’s hotspots, but one thing sticks out: CommaOperator is a rather simple piece of code (that shouldn’t need much heavy computation), but does use lopluign::Pluign::parentStmt, which rebuilds the AST to determine a node’s parent, and is really, really expensive.
Room for improvement. Time to clean up.
(At first, the generated graph looked way less interesting. One thing that was necessary was to build both LLVM/Clang and our plugin with -fno-omit-frame-pointer. The other thing was to teach FlameGraph to support “(anonymous namespace)” in C++ function names.)
