prelink performance gains

[Simo Sorce]

On Wed, 2013-10-16 at 14:58 +0200, Jan Kratochvil wrote:
> On Wed, 16 Oct 2013 14:45:00 +0200, Reindl Harald wrote:
> > why waste time and energy to fix things with little to no benefit
> 
> IIRC compiler team spends 1.5 year to get 1% of performane gain.
> Here you have almost ready feature with up to ... questionable but it is in
> a range of percents in some real world cases.

Jan it seem to me you fail to understand one key difference of a 1% gain
in gcc compared to a 1% gain in prelink.

prelink affects exclusively startup time, this means it matters only if
you keep starting up a program *many* times in a short period of time.
This behavior happens only in badly written shell scripts.

A 1% gain in gcc means that on average a program will be 1% faster
during its lifetime, not just be a smidget faster at startup, so the
reasons to work on a 15 speedup on gcc dwarf by importance anything
prelink does and is not even worth comparing IMO. They are really apples
and oranges.

What most people question is whether it makes sense to sepnd so much
time on fixing all prelink shortcomings and issues it causes to normal
systems when the gains are imperceptible to most common usage scenarios.

Personally I think the very minor startup gains prelink offer are not
worth the hassle. But let me add this. I am not against the *concept* of
prelinking if it didn't have so many annoying side issues.

For example if prelink were changed from actually modifying the binary
to instead create an extended attribute attached to the binary that
contains information to speed up load time, then it would be in a much
better position. It wouldn't taint binaries, for example.

Anyway atm I think the default should be to switch prelink off going
forward, the downsides are too big, perhaps *if* someone steps up and
fix all the bugs you pointed out in the bug you opened, then we should
reconsider.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York