[cfe-dev] clang-rename performance oddness

[Craig, Ben via cfe-dev]

I doubt that most of your time is being spent in ParseAST() itself.  
ParseAST has lots and lots of callbacks into code that does the "real" 
work.  I would expect most of the time spent to be somewhere under ParseAST.

If you are on Linux, I would recommend using 'perf' to collect your 
profile, and FlameGraph (https://github.com/brendangregg/FlameGraph) to 
visualize it.  Make sure you build with -fno-omit-frame-pointer, as 
otherwise perf will likely not have useful information.

Having assertions on can cause more overhead than you think.  When I 
last did profiling, I noticed that the allocation behavior changed a lot 
with assertions turned on.  The clang / llvm allocators would start 
poisoning and verifying empty memory during alloc / free.

On 8/16/2016 3:07 PM, Miklos Vajna via cfe-dev wrote:
> Hi,
>
> [ Resent this time without attaching a screenshot. ]
>
> I've recently tried to use clang-rename on a larger codebase
> (LibreOffice's core.git repo [1]), and while the tool works correctly, it's
> surprisingly slow.
>
> I've tried 3 actions:
>
> 1) Compiling a (somewhat random selected) file,
> sw/source/uibase/uiview/pview.cxx with clang++: it takes about 4 seconds
> on my machine.
>
> 2) Using LibreOffice's own simple rename tool [2] to rename 11 members
> of a class referenced in that translation unit: also about 4 seconds.
>
> 3) Doing the same with clang-rename: 76 seconds.
>
> So I expected that clang-rename does something stupid, but after
> building the LLVM codebase with -DCMAKE_BUILD_TYPE=RelWithDebInfo and
> used callgrind to see where time is spent, it seems that the time is
> mostly spent in clang::ParseAST().
>
> (One more thing I did not check is if -DLLVM_ENABLE_ASSERTIONS=ON is the
> source of that slowdown; but I doubt such a 19x slowdown is due to
> assertions being enabled.)
>
> I see no obvious silly in any of its callers, like calling it again and
> again inside a for() cycle or something like that. Any idea what might
> cause the 4 vs 76 seconds?
>
> I guess the problem is not specific to the above source file, but in
> case it's interesting, happy to write up and share precise, reproducible
> steps to trigger the problem.
>
> I'm not sure what's a good way to share a callgrind profile, but I've
> uploaded a kcachegrind screenshot[3]; what is a bit surprising to me is
> that the time (it seems) is spent in a single clang function that's
> called only once by clang-rename, and I guess the same function is also
> called by clang++.
>
> Any ideas how to debug such a problem?
>
> Thanks,
>
> Miklos
>
> [1] git clone git://anongit.freedesktop.org/libreoffice/core
> [2] https://cgit.freedesktop.org/libreoffice/contrib/dev-tools/tree/clang/rename.cxx
> [3] https://people.freedesktop.org/~vmiklos/2016/Screenshot_20160816_215756.png
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project