From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11616 invoked by alias); 25 Feb 2009 16:11:59 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 11604 invoked by uid 22791); 25 Feb 2009 16:11:55 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_21,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Date: Wed, 25 Feb 2009 16:11:00 -0000 From: Jan Kratochvil To: Tom Tromey Cc: archer@sourceware.org Subject: Re: [delayed-symfile] [commit] Fix a regression on delayed retrieving of the unwinding debug info. Message-ID: <20090225161139.GA5852@host0.dyn.jankratochvil.net> References: <20090224231429.GC23254@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-SW-Source: 2009-q1/txt/msg00246.txt.bz2 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