Re: [delayed-symfile] [commit] Fix a regression on delayedretrieving of the unwinding debug info.

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Wed, 25 Feb 2009 02:47:20 +0100, Tom Tromey wrote:
> [ type lookup patch ]
> Jan> Assuming (did not measure it so far) this patch will nullify any
> Jan> performance effect of this archer-tromey-delayed-symfile branch.
> 
> I think we'll still see decent benefits in some scenarios.
> 
> My canonical test case concerns two things: first, "attach"
> performance, and second, "bt" performance.  I do this by running OO.o
> Writer (with all debuginfo installed) and then attaching to it; then I
> run "thread apply all bt full".
> 
> The "attach" part shows us the biggest benefit; I think your patch
> won't affect that.  The second thing helps quantify the slowdown
> during a typical operation; it also lets us see whether incremental
> reading is really working; that is, if you do both of these things
> with -batch, you can measure performance gained by not reading some
> objfiles.
> 
> I'm still interested to hear your results.

Here is a fast (no multiple runs etc.) benchmark:

delayed-prelink-at         real 0m 7.289s
delayed-prelink-bt         real 0m26.426s
delayed-old-prelink-at     real 0m 7.795s
delayed-old-prelink-bt     real 0m26.254s
delayed-oldest-prelink-at  real 0m 2.492s
delayed-oldest-prelink-bt  real 0m27.346s
master-prelink-at          real 0m26.510s
master-prelink-bt          real 0m31.900s
fedora-prelink-at          real 0m30.343s
fedora-prelink-bt          real 0m38.688s

delayed = archer-tromey-delayed-symfile branch
master = origin/master branch, FSF GDB
         that is 2bc2becfab3f5c1771f5a344fcb678f4b559e1d7
fedora = gdb-6.8-29.fc10
-at = `attach' only
-bt = `attach' followed by `thread apply all bt full'
delayed:
(-nothing) = HEAD
-old = without: Fix a regression on forgotten delayed read of a type info.
       that is without 0b71a223391a3f8304943b24956b1a6fcaba2a16
-oldest = last Tom Tromey's commit, that is FSF GDB of Sep 16 2008
          that is 289465b302e07e4cfa44857320ddcffb670197b6

Test box: 1GB RAM, 2GB SWAP, dual Xeon(R) 5110 @ 1.60GHz

All the results above are with the fix 
  http://cvs.fedora.redhat.com/viewvc/rpms/gdb/devel/gdb-6.8-bz466901-backtrace-full-prelinked.patch?view=co
as otherwise each `bt full' backtrace gets very soon terminated with:
	layer2 = Could not find the frame base for "desktop::Desktop::Main()".
without this -prelink patch IMO the results are not useful representatives:
delayed-at                 real 0m 7.106s
delayed-bt                 real 0m17.515s
delayed-old-at             real 0m 6.427s
delayed-old-bt             real 0m 4.222s
delayed-oldest-at          real 0m 8.087s
delayed-oldest-bt          real 0m 4.282s
master-at                  real 0m28.091s
master-bt                  real 0m30.814s
(there is no fedora without -prelink)

The time difference of `master-prelink' vs. `fedora-prelink' (slower) may be
due to some other minor missed debug info, the fedora backtrace has more rich
displayed type casts.

(for RH people the box is 10.34.35.50, for non-RH people may ask for more info)


Regards,
Jan