PATCH: use hashtab for pseudo op table

[Alan Modra]

On Thu, May 05, 2005 at 12:02:02PM +0100, Nick Clifton wrote:
> Hi Alan,
> 
> >>I agree - Ben, what is your motivation for removing hash.c ?
> 
> >Probably because I was talking to Ben a week or so ago, and mentioned
> >that it's silly that we have so many hash table implementations.  We
> >have libiberty/hashtab.c, bfd/hash.c, and gas/hash.c.  Some of bfd
> >already uses libiberty/hashtab.c due to it's rather nice auto-resize,
> >and more of bfd should.  ie. I see libiberty/hashtab.c as the way of
> >the future.
> 
> Well removing multiple implementations of the same thing is certainly good.
> 
> I guess the question comes down to - should bfd keep or re-implement its 
> own hashtab code to be used everywhere in binutils or should the one 
> from libiberty be used ?  Zack pointed out the performance penalty of 
> using libiberty's code, and I would like to get a feel for whether this 
> would be a serious hindrance to using it.

I'm not convinced that the performance penaly Zack is worrying about is
real.  HJ mentioned recently that he found a 50% speedup in
sec_merge_hash_lookup by increasing the bfd hash table size.  Clearly
that was due to hash table collisions, and I'd guess that undersize hash
tables are hurting our performance on large ld jobs.  Auto-resizing to
help reduce collisions may well give a speed increase that eclipses the
penalty of extra function calls.  Of course, in the gas pseudo table
resizing isn't at all important, but then the speed of pseudo lookup in
gas isn't terribly important either.  I'd say we should focus on
improving the speed of ld on large jobs.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre