[RFA 2/4] dwarf2_physname
Mon Dec 14 19:33:00 GMT 2009
On 12/08/2009 11:47 AM, Keith Seitz wrote:
> Yeah, this is *really* bad. Really, really bad. But this was just a an
> attempt at "making it work." Now comes the "make it faster" part. I have
> a few ideas about redundant calls and whatnot, but it will undoubtedly
> take some real effort and refactoring to really make the best of this.
> I'm working on some performance numbers now with OpenOffice.org Writer
> as Tom suggested. I'll follow up on this later in this thread when I
> have some more data collected.
Okay, so I have some performance numbers for my box using CVS HEAD
patched and unpatched with my dwarf2_physname patches.
Yes, --readnow and things like "info func" and "info types" will take a
big performance hit (really big right now).
So, without further ado...
I did three tests, all with OpenOffice.org Writer, as Tom suggested. So
when you see $PID, you'll know what PID that's for.
1. time ./gdb -nx -q --batch-silent --pid $PID 2> /dev/null
real 1m14.906s 0m14.517s 0m12.229s 0m12.669s 0m12.638s
user 0m19.050s 0m11.985s 0m11.770s 0m11.738s 0m11.754s
sys 0m1.998s 0m0.484s 0m0.448s 0m0.437s 0m0.431s
real 1m6.761s 0m12.143s 0m12.070s 0m12.098s 0m12.128s
user 0m18.863s 0m11.710s 0m11.652s 0m11.695s 0m11.683s
sys 0m1.954s 0m0.420s 0m0.390s 0m0.390s 0m0.413s
2. time ./gdb -nx -q --batch-silent --pid $PID -ex "thread apply all bt
full" 2> /dev/null
real 1m9.236s 0m12.739s 0m12.619s 0m12.613s 0m12.565s
user 0m19.059s 0m12.178s 0m12.170s 0m12.166s 0m12.102s
sys 0m1.883s 0m0.433s 0m0.440s 0m0.434s 0m0.456s
real 1m8.355s 0m13.276s 0m13.211s 0m13.208s 0m13.138s
user 0m19.863s 0m12.679s 0m12.750s 0m12.708s 0m12.708s
sys 0m0.978s 0m0.465s 0m0.436s 0m0.422s 0m0.425s
3. time ./gdb -nx -q --batch-silent --readnow --pid $PID 2> /dev/null
real 10m42.371s 6m57.499s 6m2.538s 7m50.482s 6m46.206s
user 1m43.927s 1m40.768s 1m40.768s 1m40.673s 1m41.129s
sys 0m9.349s 0m7.875s 0m7.038s 0m8.751s 0m7.552s
As you can see, --readnow (and by extrapolation "info func" and "info
type") take an enormous performance hit. The dwarf2_physname patch as it
currently exists, though, appears to have a pretty minimal impact on
performance for more "normal" or "mundane" usage.
In other news, I've tested linux native using STABS, and there are two
test files that show a total of five regressions, which I am digging
into. [I've eliminated another five failures because they also exist as
"failures" in the DWARF case (the library is still using DWARF!).]
As I'm sure we all know, STABS and C++ are such horrible bedfellows to
More information about the Gdb-patches