prelink performance gains

[Josh Boyer]

On Tue, Oct 15, 2013 at 5:19 AM, Dhiru Kholia <dhiru.kholia at gmail.com> wrote:
> Hi,
>
> During the development of "unSPEC" [1] benchmarking suite, I made some
> interesting observations regarding prelink.
>
> - Here are some measurements (for LibreOffice [2] loading time in
>   seconds) done using the "unSPEC" benchmarking suite. These numbers
>   are repeatable and you are encouraged to try "unSPEC" to do
>   independent validation of these numbers.
>
>   - hkario (modern SSD based system, cache flushed): (1.816, 1.811, 1.797,
>     1.827 with prelink), (2.034, 2.042, 2.027, 2.016 without prelink)
>
>   - hkario (modern SSD based system, cache intact): (2.155, 2.121, 2.101, 2.299
>     with prelink), (2.311, 2.052, 2.047, 2.037 without prelink)
>
>   - halfie (T430s): (10.725, 10.095, 10.378, 10.568 with prelink), (8.901,
>     8.993, 9.075, 9.448, 9.489 without prelink)
>
>   - danpb (T530): I see basically no measurable difference in times with or
>     without prelink - quite a lot of variation, but all in same ballpark,
>     (8.374, 7.849, 8.457, 7.673, 7.608, 8.031, 8.350, 8.183, 7.381 with
>     prelink), (7.366, 8.009, 7.500, 7.949, 8.208, 8.351, 7.849, without
>     prelink).
>
> - For building kernels (using the "kernel-bench" [3] component of unSPEC
>   suite), prelink saved <= 250 ms over the non-prelink environment
>   (which took 1m19.138s). hkario even reports worse performance numbers
>   for the prelink environment. Additionally, we have specialized
>   softwares like ccache and distcc to solve long-compilation-time
>   problems.

I wouldn't expect building kernels to be a great thing to use to
measure performance benefits of prelink.  A kernel build is basically
just calling gcc and ld over and over, and those two things themselves
have relatively few libraries involved.  So your numbers match what I
would expect in this case, but I don't think it's really and accurate
testcase.  Prelink isn't intended to reduce compilation times.

josh