On Wed, Oct 02, 2002 at 08:43:55PM +0000, Charles M. Hannum wrote:
> 
> > I added some more tracing to ld.elf_so and have finally realised
> > why things like mozilla startup are quite so slow.
> 
> Actually, the reason Mozilla starts up slowly has little to do with
> ld.elf_so.  I traced it myself, and the reality is that Mozilla itself
> spends >80% of its startup time parsing its .xpt files.  Optimization
> that speeds up that operation would have by far the biggest impact.

I did notice it doing that twice!  However my timestamped trace of
the startup does show that most of the time between one dlopen()
returning and the net one starting is actually spent within
ld.elf_so doing 'lazy' fixups.

> That said, your `realisation' is not new.  It is in fact the origin of
> the `mark' code, which I had to remove to fix other problems that it
> caused.

How long ago was that, I might read up what it was and why it was
borken before re-implementing it!

> Part of the problem is actually the ubiquitous use of weak symbols.

Do they actually DTRT?
For instance there are references within libc to (IIRC) fseek, which
only has a week definition there....

> E.g., you can see at the very beginning of the trace that the search
> for dlsym() goes through the entire set of DAGs, even though it's
> defined in crt0 -- because it's defined as a weak symbol.

Yes, I'd noticed that weak symbols go through the DAGs, what I hadn't
worked out (yet) is why the DAG list contains repeated entries for the
same library.  Nor whether it is necessary (ever) to look at the
same library twice during a symbol search.

> It would be
> helpful if we had a way to do symbol aliasing and/or self-binding
> (c.f. libc's namespace.h) without resorting to weak symbols and the
> inherent performance loss they cause.

I used to build a shared library by compiling it as one big piece.
That way it was possible to get all the internal references to be
to local symbols and fixed up by PC relative calls by the compiler.
Setting it up for libc would be a little tedious though.

	David

-- 
David Laight: david@l8s.co.uk