Plugin, Flamed

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

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s