Re: Terminally slow (75 seconds) on some steps

[Daniel Jacobowitz <drow@mvista.com>]

On Fri, Aug 15, 2003 at 06:59:17PM -0400, Andrew Cagney wrote:
> That's striking.  GDB spent 4s/30s avoiding the creation of duplicate 
> strings and other symbols.  The lack of call graph is a shame, useful to 
> know from where this was called.  Hmm, assuming no macro debug info 
> there are only three calls, all in symtab.c:
> 
> - recording the symbol name (linkage name?)
> - recording the demangled name
> - recording a partial symbol
> 
> This is to save a significant amount of memory.  Often two files will 
> contain the same partial symbol information (due to headers et.al.).
> 
> It's interesting how linkage and demangled names (strings) share the 
> same bcache as partial symbol (a struct).  Wonder if separate caches 
> would lead to a better hit rate?
> 
> I also wonder if the full symbols are making use of the partial symbol 
> name bcache.

See SYMBOL_SET_NAMES - I fixed that fairly recently.  Also,
add_psymbol_to_list is how most partial symbols are added; that uses
the same name cache.  If you're talking about the call to bcache in
add_psymbol_with_dem_name_to_list, it's only used by hpread.c.  Fixing
this did in fact improve the hit rate.

> >c011f6b8 663       2.3393     vmlinux                  do_anonymous_page
> >00000000 622       2.1946     XFree86                  (no symbols)
> >08134b74 574       2.0253     gdb                      read_partial_die
> 
> Ok, so its spending a lot of time reading partial symbols.

I've got some plans in this direction... just haven't had time to do
anything about it yet :(

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer