[cfe-dev] clang-rename performance oddness
Craig, Ben via cfe-dev
cfe-dev at lists.llvm.org
Tue Aug 16 13:35:07 PDT 2016
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:
> [ Resent this time without attaching a screenshot. ]
> I've recently tried to use clang-rename on a larger codebase
> (LibreOffice's core.git repo ), 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  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; 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?
>  git clone git://anongit.freedesktop.org/libreoffice/core
>  https://cgit.freedesktop.org/libreoffice/contrib/dev-tools/tree/clang/rename.cxx
>  https://people.freedesktop.org/~vmiklos/2016/Screenshot_20160816_215756.png
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
More information about the cfe-dev