Re: Slow handling of C++ symbol names

[Daniel Jacobowitz <drow at mvista dot com>]

On Thu, Nov 20, 2003 at 11:54:33AM -0500, Andrew Cagney wrote:
> >
> >Well, I remember fixing some startup time issues since then :P  For
> >instance, the cache shared between minimal and partial symbols should
> >cut demangling time about in half.
> 
> Ah, this: symbol_set_names?  I was looking at the demangler.
> 
> >Which leads to the question.  Why does GDB demangle symbols?  My 
> >>simplistic understanding of the code is that GDB only needs the "iw" 
> >>(a.k.a., demangled string up to  but excluding the lparen and ignoring 
> >>white space) part of the symbol in the search table (the rest isn't so 
> >>critical and can be constructed on-demand).
> >
> >
> >A substantial amount of  demangling is needed to produce the part of
> >the symbol before the lparen; consider templates.  Also, we need the
> >full names in the minimal symbol for break 'foo(int)' with quotes to
> >work.  And there are assumptions of unique symbol names in our
> >hashing/searching, IIRC.
> 
> 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.

But does doing that save any measurable time in the demangling?  I'm
guessing very little, because of the way v3 mangled substitutions work.
Someone more familiar with the demangler could have a look at this.

Also, the demangler is currently being rewritten (again).  Result might
be faster; DJ posted it to gcc-patches a few days ago.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer