[Bug gprofng/30898] consider multi-threading for gprofng display text

[vladimir.mezentsev at oracle dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30898

--- Comment #3 from Vladimir Mezentsev <vladimir.mezentsev at oracle dot com> 
---
Hi Ruud,
See the end of emil.
He suggests to remove the disassembly by default in gp-display-html


On 9/26/23 11:09, bugmenot at mailinator dot com wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=30898
>
> --- Comment #2 from John Doe <bugmenot at mailinator dot com> ---
> (In reply to Vladimir Mezentsev from comment #1)
>> Did you try
>> gprofng display text -func /tmp/binutils-2.41/build/test.2.er
>>
>> Is this also slow?
> Sorry I didn't include that information - yes, I've tried that, and no, it's
> not slow, it works instantly.
>
>> May we get your sample program to recreate the experiment on our machines ?
> Unfortunately those "bigger" tests were done in a proprietary environment 
> where
> "perf record" is normally used instead, so I can't share that.
> Also, I _guess_ that the big disassembly (>400MB) _might_ come from the Oracle
> client, which doesn't distribute debug information.
>
>>> Also running
>>> "gprofng display text -metrics name:soname:e.%totalcpu -disasm func1"
>>>   (this function showed 5% usage in the "-functions" flavor) took 6 minutes 
>>> (that's a huge, generated function).
>> The command is incorrect. It should be:
>> gprofng display text -name short:soname -metrics e.%totalcpu:name -disasm
>> func1
> You're right about the format, but that doesn't make any difference to the 
> time
> it takes to use it.
>
> Note that when I use the "-source" option instead, I get the result within a
> few seconds.
>
> This seems to be another reason not to include the disassembly in "display
> html" by default, but only on request. Perhaps "filtered" only for some
> functions?
>

-- 
You are receiving this mail because:
You are on the CC list for the bug.