Re: Huge slowdown since 6.0

[Daniel Jacobowitz <drow@false.org>]

On Wed, Feb 18, 2004 at 01:31:12PM -0800, David Carlton wrote:
> On Wed, 18 Feb 2004 16:09:28 -0500, Daniel Jacobowitz <drow@false.org> 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