Re: optimizing a DSO

[Jakub Jelinek <jakub at redhat dot com>]

On Mon, May 10, 2010 at 05:15:51PM -0700, Ian Lance Taylor wrote:
> The most obvious change in your data is that the number of hash
> buckets dropped from 4099 to 2053.  It's entirely possible that you
> were close to the boundary of when the linker decides to increase the
> number of hash buckets.  That issue has nothing at all to do with gcc;
> it is the linker which decides the size of the dynamic hash table.

And you can use -Wl,-O1 (pass -O1 to the linker) to let the linker
determine optimal size of the hash table (minimum number of collisions
for reasonably sized section).

Note that .gnu.hash section uses a Bloom filter and stores computed
hash values in the table, so for many lookups the filter will result in no
comparison being done at all and for most collisions the expensive
comparison of symbol names isn't done either.  So, even when readelf reports
higher number of collisions, have you actually meassured a slowdown in
symbol lookup?

	Jakub