Re: PATCH: Slow linker with shared C++ libraries (sorted array)

[Andreas Jaeger <aj at suse dot de>]

"H. J. Lu" <hjl@lucon.org> writes:

> On Thu, Feb 26, 2004 at 01:11:47PM -0800, H. J. Lu wrote:
>> On Thu, Feb 26, 2004 at 11:58:05AM +0100, Lars Knoll wrote:
>> > On Thursday 26 February 2004 07:19, H. J. Lu wrote:
>> > > If a shared C++ library has many weak data definitions and many
>> > > symbols, linking against such libraries can be very slow since
>> > > elf_link_add_object_symbols has to go through all symbols for
>> > > each referenced weak data definition to search for its aliases,
>> > > although in most cases there is no alias. What is the best way
>> > > to speed it up? Can we introduce a linker command not to check
>> > > aliase for a DSO?
>> > 
>> > Michael Matz and myself made a patch to speed up weak symbol handling in the 
>> > linker, see:
>> > 
>> > http://sources.redhat.com/ml/binutils/2003-09/msg00175.html
>> > 
>> > As far as I know the patch is still not in binutils, but it sounds very much 
>> > like a solution to your problem.
>> 
>> That is the same problem. You may want to add h->type != STT_FUNC
>> when you create the hash table. In my testcase, there is no visible
>> speed difference between sorted array and hash table. Either way
>> should work for me.
>> 
>> I am enclosing the modified hash table patch here. Could someone
>> please take a look at both?
>> 
>
> Here is the updated version of sorted array approach. I'd like to
> see one of them get checked in.

Can you give us some runtime number of binutils with either patch and
without?

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SuSE Linux AG, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

Attachment: pgp00000.pgp
Description: PGP signature