Re: [patch 2/2] iFort compat.: case insensitive symbols (PR 11313)

[Tom Tromey <tromey@redhat.com>]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> There is more an issue MINIMAL_SYMBOL_HASH_SIZE is constant:
Jan> 	#define MINIMAL_SYMBOL_HASH_SIZE 2039
Jan> Some objfiles have many symbols:
Jan> 	libwebkit.so.debug: 54980 symbols
Jan> 		/MINIMAL_SYMBOL_HASH_SIZE = 27
Jan> 		log2(54980)=16

I looked at this a long time ago, when I was trying to reduce memory use.

My recollection is that our hashing here is pretty bad.  I seem to
remember a case where we had some empty hash buckets and some buckets
with 20 symbols.

Jan> In such case in fact the whole hash table makes no sense and it is even
Jan> cheaper to just do binary search on objfile->msymbols which is already
Jan> qsort-ed and be done with it.

msymbols is sorted by address first.

Note that changing this area is trickier than it seems due to the
mst_solib_trampoline handling in lookup_minimal_symbol (maybe obvious,
but it took me a while to realize it...).

Jan> Still a hash table should be faster than a binary search but the
Jan> hash table size would need to be adaptable.

I implemented this :-).  It slowed down startup, so it didn't go in.
See the archives around 2008-08-27.  Given your other comments this hit
may not be relevant.  I still have the patch if you are interested.

Jan> But rather than optimizations of this which reduce just the CPU
Jan> load which was in my measurements 2% during GDB startup (due to its
Jan> waiting on disk).  We could for example rather delay
Jan> searching+loading any objfiles' symbols we do not need which would
Jan> do another major GDB startup time reduction like .gdb_index did.

Yeah, this would be interesting to see.  I think find_main_filename may
make this difficult, but maybe it would work ok for the attach case.

This sort of reading could maybe be done in a background thread.

Also, I wonder why we read minsyms from separate debuginfo files.
Is that ever needed?

Tom