Performance testing (pass 1)

[Jakub Jelinek]

On Sat, Sep 27, 2003 at 03:42:20AM -0300, Thiago Vinhas de Moraes wrote:
> Em Sáb, 2003-09-27 às 03:25, Ingo Molnar escreveu:
> > note that prelinking is different and not related to preloading - did you
> > have prelink enabled? (it's default enabled but might take a day on a
> > freshly installed desktop to take full effect.)
> 
> Ingo, what's exactly is prelink, and how it works? I never heard about
> it on past RH versions. It's kernel or user level?

See man prelink.

In short, it is a tool which modifies binaries/libraries, such that
they can be started faster.
If you run applications with LD_ASSUME_KERNEL=statistics, you see
results like this:

LD_DEBUG=statistics konqueror
     17726:
     17726:     runtime linker statistics:
     17726:       total startup time in dynamic loader: 136644448 clock cycles
     17726:                 time needed for relocation: 132727549 clock cycles (97.1%)
     17726:                      number of relocations: 25536
     17726:           number of relocations from cache: 59201
     17726:                time needed to load objects: 3581812 clock cycles (2.6%)

(this is not prelinked binary).
prelink cannot do anything about "time needed to load objects",
but it can drastically decrease "time needed for relocations"
(which in this example takes 97.1% of the startup time in ld.so).
There are no relocations to be applied in prelinked binaries and libraries
they are linked against, only conflict fixups which are typically much
fewer than relocs and don't need any symbol lookups (the most costly
part of relocating).

But note that time spent in the dynamic linker is just one part of the
time spent since you run say a GUI command till it paints its windows
and is ready to be used. The other time is spent in aplication code
which prelink cannot influence much.

The modifications of the binaries/libraries is such that if any of the
dependent libraries are e.g. upgraded or otherwise modified, the binaries
or libraries still work, but cannot use prelinking until
they are reprelinked again (this is by default on Fedora Core Test 2
done nightly in a cron job if needed) and when the user desires so
the binaries/libraries can be reverted back (unprelinked) into the
original image.

Other than speeding up time spent in ld.so for relocating the binary
and its libraries, prelink can also speed up slightly execution:
a) when prelinking is used, the behaviour is as if LD_BIND_NOW=1
   has been specified, ie. there is no lazy binding of initially loaded
   objects - all needed relocation is done at startup time; this only
   decreases time you need during first call to a function from given
   binary or library, second and later calls have the same speed both
   with and without prelinking
b) C++ virtual methods don't need to hop through .plt slot in binary,
   the tables are modified such that it jumps directly to the desired
   method (this is just a few cycles, but the difference in speed
   remains the same until the application exits)

	Jakub