[cfe-dev] clang-rename performance oddness
Craig, Ben via cfe-dev
cfe-dev at lists.llvm.org
Wed Aug 17 09:22:50 PDT 2016
In looking at the top level code, I do see one thing that I don't
particularly care for...
Each symbol to be renamed causes a new frontend action to be taken.
That eventually means a full re-parsing of the AST. I would hope /
expect that I could gain significant performance by passing multiple
renamings in one clang-rename invocation, but that doesn't look to be
So the problem isn't that ParseAST() is slow, it's that it's being
called too many times.
On 8/17/2016 10:18 AM, Craig, Ben via cfe-dev wrote:
> The profile you shared is showing 12% of the samples coming from the
> swapper. That suggests that something (likely Firefox and/or
> plasmashell) are taking up a lot of memory and causing general
> performance problems.
> During the run of clang-rename, you may want to look at top and see
> how much memory is being used by clang-rename (as well as other
> processes). Maybe that's just an artifact of the perf run though. I'm
> not used to seeing a flame graph with such deep stacks.
> On 8/17/2016 9:13 AM, Miklos Vajna wrote:
>> On Tue, Aug 16, 2016 at 03:35:07PM -0500, "Craig, Ben via cfe-dev"
>> <cfe-dev at lists.llvm.org> wrote:
>>> 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.
>> Yes, I guess so; though I could not identify a single hotspot in the
>> called methods.
>>> If you are on Linux, I would recommend using 'perf' to collect your
>>> and FlameGraph (https://github.com/brendangregg/FlameGraph) to
>>> visualize it.
>>> Make sure you build with -fno-omit-frame-pointer, as otherwise perf
>>> likely not have useful information.
>> Ah great, that allows me to share the recorded profile, unlike valgrind:
>>> Having assertions on can cause more overhead than you think. When I
>>> did profiling, I noticed that the allocation behavior changed a lot
>>> assertions turned on. The clang / llvm allocators would start
>>> poisoning and
>>> verifying empty memory during alloc / free.
>> Hmm, indeed. Disabling assertions helps a bit, now clang-rename is down
>> from ~75 secs to 60 secs. But still a large ~60 vs 5 seconds gap.
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