On Tue, 6 Sep 2011 19:01:57 +0200, Jan Kratochvil <jan.kratochvil@xxxxxxxxxx> wrote: > On Tue, 06 Sep 2011 17:39:55 +0200, Gordan Bobic wrote: >> Can you elaborate as to why? My experience and measurements show >> that >> prelink does more harm than good more offten than not. I can think >> of a >> lot of reasons to not use it, and very few reasons to use it. > > It speeds up the program startup up to 50% (you can Google out > various > benchmarks). I did, and found no definitive, reproducible results to support the 50% claim. It certainly wasn't corroborated by my own measurements - last time I tested what benefit it gives, the results were at best inconclusive. > As almost any performance feature it sure comes with more > complexity of the ELF files handling. The most easy ELF files > processing > would be with -O0 code - so why do we build the programs with -O2? > > Nowadays some people do not consider performance as anything to care > about so > in such case it is understandable they do not see a need for prelink. The only performance claims that are worth listening to are the ones supported by evidence showing consistent and reproducible improvement - and I have seen no such thing to support prelink recently. And I just thought of another reason to not use prelink, in addition to tripwire/IDS issues and vserver's hashify feature - flash media. Rewriting a large chunk of your binaries on a semi-regular basis isn't going to help the longevity of a system running off cheap flash media, as most ARMs are doing. > It is true that if program is written in C it is usually fast enough. > But specifically ARM may be the only popoular platform where I do not > find the C programs fast enough, though. If we're going to argue the performance toss, rewriting yum in C would be a good start toward addressing the eyewateringly big performance issues. Compared to that, anything that prelink could possibly achieve gets lost in the noise. To summarize - I'm unconvinced of the benefits of prelink. But I will happily be persuaded otherwise by reasonably broad and repeatable empirical evidence. Gordan _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
