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

["H. J. Lu" <hjl at lucon dot org>]

On Fri, Feb 27, 2004 at 06:54:30AM +0100, Andreas Jaeger wrote:
> "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?
> 

There are no visible speed differences between sorted array and hash
table. Without any patch, real link time is 20.7 seconds. With either
patch, real link time is 2.7 seconds.


H.J.