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.
