[cfe-dev] clang-rename performance oddness

[Craig, Ben via cfe-dev]

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