(resend without trace file extract)

I added some more tracing to ld.elf_so and have finally realised
why things like mozilla startup are quite so slow.

The place to trace is the strcmp() call in _rtld_symlook_obj().
I don't have enough free disk space for the trace output file :-(
(ok, it is only 500Mb - too big to look at)

One fairly early lookup of dlsym involves 703 string compares,
only 38 of which are actually unique.
see http://www.btinternet.com/~david.laight/netbsd/ld.elf_so/mozilla_trace.txt

Looking at the trace shows that a lot of repetitive searching
is being done, and that a better way of handling the symbol
table search is needed.

In particuler the 'Search all dlopened DAGs containing the referencing
object.' loop (in _rtld_find_symdef) is rather repetitive.
Note that it checks libjsd.so 9 times, and that each pass checks
some objects several times.

Even the search for a global symbol seems to use the same symbol
tables as the earlier program body search.

Leafing through the early part of the full trace shows that the
symbol table hashing often leaves chains of 4 or 5 symbols. When
compounded with repeated searches of multiple shared libraries
it is hardly surprising things are sluggish.

It maybe worth saving the symbol table info in an entirely
different structure - optimised for each name only being
defined once.

	David

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