[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.