From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24286 invoked by alias); 13 Jun 2003 15:38:49 -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 24215 invoked from network); 13 Jun 2003 15:38:48 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.131) by sources.redhat.com with SMTP; 13 Jun 2003 15:38:48 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id E139C2B5F; Fri, 13 Jun 2003 11:38:38 -0400 (EDT) Message-ID: <3EE9EFFE.6050607@redhat.com> Date: Fri, 13 Jun 2003 15:38:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Elena Zannoni , Daniel Jacobowitz , David Carlton Cc: gdb , Jim Blandy Subject: Re: DW_AT_specification and partial symtabs 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-06/txt/msg00251.txt.bz2 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. 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. > > 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) were totally bogus. But having said that, wasn't there a proposal to fix/rewrite BFD's mmap interface? I think what's needed is a proper comparison of the current contents of the symbol tabe VS exactly what and how often GDB requests that info. For dwarf2, for instance, it now reads in all the location expression stuff, and that, relatively speaking, is never used. If psymtab's are dumped (or at least burried) the core GDB <-> symtab interface is simplified/tightened, people can change the internals without breaking everything. David, I belive, has been working in that direction. Andrew