This is the mail archive of the
mailing list for the binutils project.
Re: tuning ld performance
- From: Michael Matz <matz at suse dot de>
- To: Andy Chittenden <achittenden at bluearc dot com>
- Cc: "'binutils at sources dot redhat dot com'" <binutils at sources dot redhat dot com>,Martin Dorey <mdorey at bluearc dot com>
- Date: Mon, 26 Jan 2004 12:59:27 +0100 (CET)
- Subject: Re: tuning ld performance
- References: <AD4480A509455343AEFACCC231BA850F086C2E@ukexchange>
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).
> 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.