Re: Huge slowdown since 6.0

[Daniel Jacobowitz <drow at false dot org>]

On Wed, Feb 18, 2004 at 08:54:54PM -0500, Elena Zannoni wrote:
> Daniel Jacobowitz writes:
>  > I finished prototyping my partial-symbol-sorting changes, as discussed on
>  > gdb-patches, and went to measure their impact.  The results were a little
>  > confusing, but I've tracked them down.  At the bottom of my message are
>  > profiling numbers if you want to see them.  The summary is that I hope they
>  > won't be needed.
>  > 
>  > Basically, the bottleneck in strcmp_iw_ordered that I am attacking was not
>  > there in 6.0.  This baffled me.  There were just as many psymbols and there
>  > should have been just as many calls; the change to use strcmp_iw_ordered
>  > predates 6.0.
> 
> 
> How many psymbols do you have in the pst list of globals before and
> after David's change? All you did was to time the times it took to
> insert symbols and sort them, no lookups, right?

That's right - just insertion and sorting.  Lookups are fast; the
binary search isn't quite as nice as a hash table would be but it's
still pretty quick.  It's just insertion that hurts us.  Perhaps a more
efficient representation is on order.

GDB 6.0:
(gdb) p object_files.global_psymbols.size
$4 = 3264
(gdb) p object_files.static_psymbols.size
$5 = 835584
(gdb) p object_files.stats.n_psyms
$3 = 829406

GDB HEAD:
(gdb) p object_files.global_psymbols.size
$1 = 835584
(gdb) p object_files.static_psymbols.size
$2 = 417792
(gdb) p object_files.stats.n_psyms
$3 = 829406

Um... I'm not precisely sure why these numbers don't add up.  I notice
they didn't before either.

By the way, do we even need the address field from general_symbol_info
in psymbols?  I haven't checked thoroughly but I suspect that most of
the places we currently use it, the symtab will usually be read in
shortly afterwards anyway.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer