Re: Huge slowdown since 6.0

[Kip Macy <kmacy@fsmware.com>]

About a year ago our tools person added symbol-caching to our in-house
GDB tree. He happened to use an STL map, although there are certainly
more C-compliant ways. Prior to this change, developers had to use
pointer arithmetic in their macros to avoid repeated lookups or their
macros would run too SLOW. Would symbol-caching be something that would
make sense for mainline GDB?

				-Kip


On Wed, 18 Feb 2004, 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.
>
> David Carlton
> carlton@kealia.com
>