Re: tuning ld performance

[Jakub Jelinek <jakub at redhat dot com>]

On Mon, Jan 26, 2004 at 12:59:27PM +0100, Michael Matz wrote:
> Hi,
> 
> On Mon, 26 Jan 2004, Andy Chittenden wrote:
> 
> > Secondly, after putting in the return statement, the next routine on the
> > radar, bfd_hash_lookup, is taking 67% of CPU. As the major callers are
> > _bfd_stringtab_add (from _bfd_link_section_stabs) and
> > _bfd_link_section_stabs itself, it seems this could be stabs related but we
> > obviously need them for debugging.
> 
> This is probably related to section merging of string tabs (although for 
> stabs I'm not sure).

Well, unless we know the details what the measurements were done on,
it is hard to guess.  What options were used during the link, how many input
files, how many sections on average, what sections were being discarded most etc.

> > Again, is there an easy way of either making this routine more efficient
> > or removing calls to it?
> 
> There is no totally easy way.  One way I tried is to make GCC emit the 
> hash value for each string and use that one while merging (instead of 
> calculating it on demand).  But the major time sink in that routine 
> actually are cache misses, and those don't go away, because while merging 
> the strings they still have to be compared (i.e. read in).  That said the 
> resulting ld was a bit faster, but not that much.  And at the expense of 
> larger debug sections because of the added hash value per string.

FYI 2.14.90.0.7 did not have merge speedup patches in (unless Debian applied
it to their release).
So it would be better to get numbers from 2.14.90.0.8 or CVS.

	Jakub