bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: bugmenot at mailinator dot com
Subject: [Bug gprofng/30898] consider multi-threading for gprofng display text
Date: Tue, 26 Sep 2023 18:09:55 +0000

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]