[cfe-dev] clang-rename performance oddness

[Craig, Ben via cfe-dev]

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 
the case.

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:
>> Hi,
>>
>> 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 
>>> 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.
>> Ah great, that allows me to share the recorded profile, unlike valgrind:
>>
>> https://people.freedesktop.org/~vmiklos/2016/clang-rename.svg
>>
>>> 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.
>> 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.
>>
>> Regards,
>>
>> Miklos
>

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