From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23795 invoked by alias); 13 Jun 2003 15:50:29 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 21748 invoked from network); 13 Jun 2003 15:49:38 -0000 Received: from unknown (HELO crack.them.org) (146.82.138.56) by sources.redhat.com with SMTP; 13 Jun 2003 15:49:38 -0000 Received: from dsl093-172-017.pit1.dsl.speakeasy.net ([66.93.172.17] helo=nevyn.them.org ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 19Qqon-0002C8-00; Fri, 13 Jun 2003 10:50:21 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19Qqo0-00006W-00; Fri, 13 Jun 2003 11:49:32 -0400 Date: Fri, 13 Jun 2003 15:50:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Elena Zannoni , David Carlton , gdb , Jim Blandy Subject: Re: DW_AT_specification and partial symtabs Message-ID: <20030613154932.GA313@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Elena Zannoni , David Carlton , gdb , Jim Blandy References: <20030612170545.GA16995@nevyn.them.org> <16104.47067.182016.78574@localhost.redhat.com> <20030613133414.GB29641@nevyn.them.org> <16105.55964.91811.625007@localhost.redhat.com> <3EE9EFFE.6050607@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EE9EFFE.6050607@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-06/txt/msg00254.txt.bz2 On Fri, Jun 13, 2003 at 11:38:38AM -0400, Andrew Cagney wrote: > Daniel wrote: > > > > > 1) is very easy to measure. GDB has a command line option --readnow > > > which forces symtabs to be read in immediately. I tried my normal > > > performance testcase: a dummy main() linked to all of mozilla's > > > component libraries, with full stabs debug info. Note stabs, not > > > DWARF2, so the timing may vary. Also note that we duplicate psymtab > > > and symtab creation doing it this way, so it overestimates the cost. > > I think that's an understatement. Not really. You can subtract the psymtab time from the combined time, and then compare. It still more than triples the time. > Elena wrote: > > >But with --readnow we do both psymtabs and symtabs. I wonder, if we > >didn't do psymtabs at all, the time would improve, one hopes. > >And the memory footprint would shrink too. > > Some back of envelope caculations are in order. > > ``(gdb) print sizeof (struct ...) indicates that sizeof(symtab) ~= > 2*sizeof(psymtab) so GDB is burning 33% of allocated memory. Assuming > memory and file I/O are the bottle neck, slashing 33% of memory should > slash 33% of the time. > > I just hope GDB isn't doing something stupid like searching psymtab > before symtab. That neglects type information, which we don't really build during psymtab reading, and is a huge memory sink. > > > Note that none of those times is really acceptably fast, IMHO. Probably > > > they all can be improved. Looking at profiling data I see about three > > > seconds we can knock off the symbol reader and there are almost > > > certainly more. > > I think oprofile data would be far more useful - remember the thread > problem where the profile data (and its suggested micro-optimizations) Ah, but you can back-of-the-envelope simulate this easily without oprofile. Build without -pg, use maint set profile. It does only flat profiling using a timer, and is fairly accurate. > were totally bogus. But having said that, wasn't there a proposal to > fix/rewrite BFD's mmap interface? Yes, but who knows when it'll happen. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer