On Tue, Jul 04, 2006 at 10:36:35AM +0930, Alan Modra wrote:
> On Mon, Jul 03, 2006 at 10:42:31AM +0200, Jakub Jelinek wrote:
> > On Mon, Jul 03, 2006 at 03:43:52PM +0930, Alan Modra wrote:
> > > I'm not so sure about this change, which affects both 32-bit and
> > > 64-bit.  If I've analysed the change correctly, it will tend to result
> > > in smaller hash tables at the expense of possibly longer chains, in both
> > > the optimising and non-optimising cases.  Do we really want that?
> > 
> > Well, if we want to use a bigger number, we certainly can, not sure if
> > we want some multiply of (hashcodesp - hashcodes) or just add some constant
> > (i.e. say (hashcodesp - hashcodes) * 1.1 < elf_buckets[i + 1] or
> > (hashcodesp - hashcodes) + 20 < elf_buckets[i + 1]).
> 
> No, I don't want to see fudge factors like this!
> 
> >  What I'm just trying
> > to say that the heuristics should have nothing to do with dynsymcount,
> > it really shouldn't care how many special symbols you have in .dynsym that
> > are not added to the hash table.
> 
> Yes, I agree with your change from a logical perspective.  I wasn't
> saying that I disliked the new heuristic, just noting that your change
> potentially causes longer chains.  Have you done any tests to see
> whether there is in fact any real world effect?

I have some raw data for the same binaries/libraries built without my first
DT_GNU_HASH patch and after it (that patch included also the arch_size / 8
-> bed->size_of_hash_entry change, nsyms -> dynsymcount in ld -O1 code
and dynsymcount -> (hashcodesp - hashcodes) in non-optimizing compute_bucket_count).
For .gnu.hash, one shouldn't look at the st_size of .gnu.hash section,
that was decreased by (2 * nchains - 1) * 4 with the patch from yesterday.

Apparently very few packages use -Wl,-O1 (glibc is a notable exception)
and for non-optimizing linking the dynsymcount -> (hashcodesp - hashcodes)
change in many cases decreases the bucket counts.  It is just itching me
because the heuristics uses completely unrelated value, a fudge factor would
be ugly, but at least would make some sense.

In any case, I can live with that for .hash section, for .gnu.hash
we don't mind slightly longer chains as long as they aren't much longer.

	Jakub