[ 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
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