Re: Slow handling of C++ symbol names

[Daniel Jacobowitz <drow at mvista dot com>]

First of all, please use gdb@, not gdb-patches@.

On Wed, Nov 19, 2003 at 04:09:59PM -0500, Will Cohen wrote:
> When debugging some C++ program with gdb (both versions 5.3 and 6.0) it 
> takes a long time to load the debugging information and get a 
> command-line prompt. The particular example that demonstrates this 
> problem is monotone (http://www.venge.net/monotone/) which makes use of 
> the boost libraries (http://www.boost.org/). gdb loading monotone with 
> the associated debugging information takes over 30 seconds to get the 
> initial command-line prompt on a 1.7GHz Athlon with 512MB or DRAM. 
> monotone is not a small program, over 3MB of debugging information. I 
> tooks some measurements with OProfile to find out where gdb 5.3 was 
> spending its time. 3/4 of the time is spent in dyn_string_substring and 
> __GI_strncpy, the column below the '%'. I recompiled gdb with '-pg' to 
> find that this is due to the C++ name demangling. The highlights of 
> gprof output are shown below. I looked at the symbols for monotone/boost 
> in the executable, some of them are VERY long and for monotone/boost 
> they average 147 characters in length. An example of ONE symbol over 2KB 
> is at the end of this mail (there are others like that). I suspect that 
> some of the algorithms used in gdb may not expect such long symbol names 
> and be part of the reason for the slow startup, e.g. work 
> O(length_of_string ^2). Has anyone else noticed this type of problem before?

Have you tried a more recent version of GDB?  This may have been
improved.  Definitely some startup time issues were fixed.

Also, the demangler actually comes from GCC, not GDB.  All we can do is
try to call it less often.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer