Re: Terminally slow (75 seconds) on some steps

Daniel Jacobowitz
2003-08-16T15:11:25Z

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