ld.so optimizations

[Keld Jørn Simonsen <keld at dkuug dot dk>]

Hi!

Is this the right list for discussing ld.so issues?
I notice that at least on my distribution (mandrake 10.1 on a i586)
ld.so is part of the glibc package.

My issue is that I was annoyed with the time it takes to load
openoffice.org. On my laptop it takes about 23 secs at the initial load.

I did some measurment with vmstat of what was going on and noticed
that in the first phase there was about 10 secs of almost nothing but
reading. About 64 MB was read, and the cpu usage was about 3 %. 
I then looked at the speed I could just read the data, - that is the
*.so files for ooo, and that could be done (with a cat *.so) in
about 4 secs for 64 MB, on my laptop (where a hdparm -t /dev/hda gives a
transfererate of about 22 MB/s).

So I thought that with some care one could save about 6 secs in this
first phase. 

I then looked in the sources for the ld.so (2.3.3) and tried to grasp
what was going on in rtld.c but it was a bit hard to get global view.
I also read parts of Ulrich's DSOHOWTO document.  Is there an
introduction to how ld.so is structured? I especially would like to see
where the *.so files were read in and where alloaction of memory for the
instruction and data segments were done.

I also tried some experiments with LD_DEBUG - but had some trouble 
controlling it. 'all' gave too much output, and I could not find ways to
specify more than one option to LD_DEBUG. Can that be done?

I tried to set an output file with setenv LD_DEBUG_OUTPUT /tmp/ooo
but nothing appeared in /tmp/ooo. Waht could have gotten wrong here?

I think the first argument on the debug output is a kind of time, in the
granuarity of 1 sec? Is that so? And then 1 sec is a bit coarse for
investigating - is it possible to get at least microsecond accuracy?

Does anybody know why the ld.so is not reading in the *.so files at full
speed (only about one third speed is achieved)?

Best regards
Keld