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