Re: Slow handling of C++ symbol names

[Will Cohen <wcohen at redhat dot com>]

Andrew Cagney wrote:
> > But without looking at the data we've no idea how substantial any
> >
> > > particular part really is.  For instance, when analysing the bcache 
> > > found that when debugging a C program every entry is 28 bytes in size!
> > >
> > > 'foo(int)' can be broken down into "foo" "(int)" the latter only 
> > > being demanged and stored on-demand.
> >
> >
> >
> > "They" tell me that the demangler did not support doing this.  But it
> > may soon.
> >
> > Will, you may want to test a CVS snapshot from today or later.  The
> > demangler for GNU v3 was replaced last night; the new one appears to be
> > about twice as efficient.
>
>
> FYI, Will got hold of an RPM based on 20031117 and I believe the 
> performance numbers came back the same as 6.0 :-(  That would make it 
> post your changes but pre the new demangler.
>
> I guess we get to restart the analysis :-(
>
> Andrew

I tried building a uberbaum tree with a snapshot this morning 
(2003/11/26). The uberbaum built a gdb, but didn't complete building 
everything.

I tried using this gdb with the new demangler on the monotone executable 
that take 30 seconds or so to load. gdb segfaults when loading the 
debugging information. This is definitely caused by reading in the 
debugging information. gdb was able to read in a stripped version of the 
same file and the gdb dies in libiberty/cp-demangle.c:d_print_comp which 
is called from demangler.

I have made the monotone files available at 
http://people.redhat.com/wcohen/gdb_tuning/

--Will