Re: OO.o / ld / -Bsymbolic patch ...

[Jakub Jelinek <jakub at redhat dot com>]

On Tue, Jul 05, 2005 at 03:17:29PM +0100, michael meeks wrote:
> 	OO.o startup performance then sucked so, so badly that we spent ages
> marking everything up with visiblity attributes. This improved matters
> somewhat. However - we still have a huge number of relocations.
> To give some idea - on warm start, we take ~4secs on my machine, and
> ~25% of that is processing relocations ;-) this is not good.

That begs the question, are you using prelink or not?
Looking at current OOo 2.0 as is, prelink can help only partly there.
On x86-64 FC4 box with 32-bit OOo 2.0, I'm getting following numbers.
This is on a prelinked system, so I use LD_PRELOAD=libSegFault.so
to make prelinking useless (libSegFault.so has < 30 relocations,
so shouldn't change the numbers much):

LD_PRELOAD=libSegFault.so LD_DEBUG=statistics oowriter
      4630:
      4630:     runtime linker statistics:
      4630:       total startup time in dynamic loader: 88781060 clock cycles
      4630:                 time needed for relocation: 76109044 clock cycles (85.7%)
      4630:                      number of relocations: 15209
      4630:           number of relocations from cache: 31656
      4630:             number of relative relocations: 3
      4630:                time needed to load objects: 11919621 clock cycles (13.4%)
      4630:
      4630:     runtime linker statistics:
      4630:                final number of relocations: 62756
      4630:     final number of relocations from cache: 121745
LD_DEBUG=statistics oowriter
      4669:
      4669:     runtime linker statistics:
      4669:       total startup time in dynamic loader: 14338451 clock cycles
      4669:                 time needed for relocation: 1981963 clock cycles (13.8%)
      4669:                      number of relocations: 0
      4669:           number of relocations from cache: 9792
      4669:             number of relative relocations: 0
      4669:                time needed to load objects: 11516134 clock cycles (80.3%)
      4669:
      4669:     runtime linker statistics:
      4669:                final number of relocations: 43733
      4669:     final number of relocations from cache: 99881

Now, there is still significant overhead processing the relocations
(times not included in the clock counts though, as that's after main was
called).  The most expensive relocations are those not on the 
"from cache:" lines, they need the expensive symbol lookup.  Relocations
from cache as well as prelink fixups (also reported as relocations from
cache) are fairly cheap.

A useful experiment would be to link a bunch of soffice.bin programs, each
with the libraries current soffice.bin library already links against plus
libraries listed in the corresponding pagein-* file, then prelink all of
them.  I guess startup time of say swriter.bin etc. would go significantly
lower.  There is a disadvantage to doing that, if you start such say
swriter.bin and then open say impress from that and close all writer
windows, then the writer specific shared libraries that were this way
linked into swriter.bin will not be actually released (but text pages from
them simply discarded from memory if unused for some time and writable
pages paged out).

	Jakub