From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4851 invoked by alias); 13 Jun 2003 13:36:57 -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 32413 invoked from network); 13 Jun 2003 13:34:23 -0000 Received: from unknown (HELO crack.them.org) (146.82.138.56) by sources.redhat.com with SMTP; 13 Jun 2003 13:34:23 -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 19Qohs-0001w4-00; Fri, 13 Jun 2003 08:35:04 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19Qoh5-0007oy-00; Fri, 13 Jun 2003 09:34:15 -0400 Date: Fri, 13 Jun 2003 13:36:00 -0000 From: Daniel Jacobowitz To: David Carlton Cc: Elena Zannoni , gdb , Jim Blandy Subject: Re: DW_AT_specification and partial symtabs Message-ID: <20030613133414.GB29641@nevyn.them.org> Mail-Followup-To: David Carlton , Elena Zannoni , gdb , Jim Blandy References: <20030612170545.GA16995@nevyn.them.org> <16104.47067.182016.78574@localhost.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-06/txt/msg00242.txt.bz2 On Thu, Jun 12, 2003 at 03:16:58PM -0700, David Carlton wrote: > On Thu, 12 Jun 2003 13:26:51 -0400, Elena Zannoni said: > > > I wonder, if we are not reaching the end of the usefulness of the > > psymtabs. I mean, if we start making the psymtab reader behave like > > the symtab reader, how much faster is that going to be, how much > > smaller, etc. > > Yeah, I'm starting to wonder that, too. This particular situation is > enough of an edge case that I'm actually tempted not to fix the > psymtab reader until I get bug reports from users complaining about > it, because if I do fix it completely then I'll probably make the > psymtab reader slow, make it duplicate lots and lots of the > functionality of the symtab reader, and do it in such a way as to > cause code duplication that will lead to bugs as the two versions slip > out of sync. So I'm tempted to let things be for now, and wait until > .debug_pubtypes comes along to save the day. > > I guess another possibility would be to merge the symtab reader and > psymtab reader, and have there be some variable 'reading_psyms' or > whatever to control what sort of symbols we're creating, how deeply we > descend into trees, etc. > > It would be interesting to find out the following: > > 1) How much is the savings for building a psymtab vs. building a > symtab? > > 2) Where is that savings coming from? > > If the savings largely comes from not descending into the bodies of > functions, then the current structure should go: we should just merge > the psymtab and symtab readers, but have some flag floating around > that controls whether or not we descend into bodies of functions. 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. But it should give you an idea. Psymbols 5.3: gdb --batch -x a ./mozilla-libs 17.34s user 1.72s system 78% cpu 24.160 total Psymbols and symbols 5.3: gdb --batch -x a ./mozilla-libs --readnow 41.20s user 4.93s system 83% cpu 55.207 total Psymbols CVS: /opt/src/gdb/x86-as/gdb/gdb --batch -x a ./mozilla-libs 8.79s user 1.01s system 99% cpu 9.850 total Psymbols and symbols CVS: /opt/src/gdb/x86-as/gdb/gdb --batch -x a ./mozilla-libs --readnow 30.45s user 2.70s system 94% cpu 35.131 total 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. Andrew's suggested in the past that (rather than all-at-once) we read symbols lazily; that's essentially like the status quo but without a separate psymtab table. I don't know how much that saves us. Keep in mind that symbols are (at present) rather memory-intensive compared to psymbols. Also keep in mind that we build more type information when reading symbols - more time, more memory. One quick thing we can do to speed up DWARF2 symbol reading is to finish converting the rest of GDB to runtime-computed locations; then we won't have to parse location lists or location expressions at load time. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer