From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14265 invoked by alias); 20 Feb 2004 05:09:15 -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 14186 invoked from network); 20 Feb 2004 05:09:08 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 20 Feb 2004 05:09:08 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1Au2uQ-0004N6-CX; Fri, 20 Feb 2004 00:09:06 -0500 Date: Fri, 20 Feb 2004 05:09:00 -0000 From: Daniel Jacobowitz To: David Carlton Cc: gdb@sources.redhat.com Subject: Re: Huge slowdown since 6.0 Message-ID: <20040220050905.GA15209@nevyn.them.org> Mail-Followup-To: David Carlton , gdb@sources.redhat.com References: <20040218210927.GA16641@nevyn.them.org> 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: 2004-02/txt/msg00273.txt.bz2 On Wed, Feb 18, 2004 at 01:31:12PM -0800, David Carlton wrote: > On Wed, 18 Feb 2004 16:09:28 -0500, Daniel Jacobowitz said: > > > The only reasonable explanation is that the number of global symbols has > > vastly increased. This appears to be the case. David, the blame appears to > > be yours, in dwarf2read.c revision 1.120: > > > @@ -1519,14 +1556,16 @@ add_partial_symbol (struct partial_die_i > > /* For C++, these implicitly act as typedefs as well. */ > > add_psymbol_to_list (actual_name, strlen (actual_name), > > VAR_DOMAIN, LOC_TYPEDEF, > > - &objfile->static_psymbols, > > + &objfile->global_psymbols, > > 0, (CORE_ADDR) 0, cu_language, objfile); > > } > > break; > > case DW_TAG_enumerator: > > add_psymbol_to_list (actual_name, strlen (actual_name), > > VAR_DOMAIN, LOC_CONST, > > - &objfile->static_psymbols, > > + cu_language == language_cplus > > + ? &objfile->static_psymbols > > + : &objfile->global_psymbols, > > 0, (CORE_ADDR) 0, cu_language, objfile); > > break; > > default: > > > Could you re-explain the need for this change, please? You said: > > > + /* NOTE: carlton/2003-11-10: C++ class symbols shouldn't > > + really ever be static objects: otherwise, if you try > > + to, say, break of a class's method and you're in a file > > + which doesn't mention that class, it won't work unless > > + the check for all static symbols in lookup_symbol_aux > > + saves you. See the OtherFileClass tests in > > + gdb.c++/namespace.exp. */ > > + > > > but is that also necessary for enumerators? As things stand, one > > large enum in a used header can lead to worse-than-linear slowdown > > of GDB startup for DWARF-2, and a couple megabytes of wasted memory. > > Crap. Well, in some sense, enumerators really are global in C++: it's > illegal to have two different enums in the same scope that have an > enumerator with the same name. (I'm pretty sure.) So, in the > mythical future super-groovy-GDB where we coalesce all sorts of > type-related debug information across files, it would be nice if, in > the C++ case, enumerators were treated as global (and were coalesced). > > Having said that, it should be the case that handling enumerators this > way is much less important than handling class symbols this way. I > can't quite envision the consequences of reverting the change for > enumerators; it will mean that you can't print out enumerators that > are defined in namespaces and that aren't in the debug info for the > current source file (if any), but that doesn't sound like too big a > deal to me. OK, boot to the head time. My testcase is in C. These are all conditionalized on language_cplus. How can they possibly be to blame? Well, they are. And reverting the change for enumerators definitely won't do any harm. Take a look at this, read it two or three times if necessary - it took me about a dozen: > > - &objfile->static_psymbols, > > + cu_language == language_cplus > > + ? &objfile->static_psymbols > > + : &objfile->global_psymbols, If I swap "static" and "global", it reduces GDB startup time by roughly 40% for glibc with debug information, which contains a lot of C enumerators. I assume that is what you meant to do in the first place? If so I can recover the speed hit for C for GDB 6.1, and then address the larger issues with large numbers of global psymbols in HEAD after we branch. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer