prelink performance gains

Josh Boyer jwboyer at gmail.com
Tue Oct 15 13:51:05 UTC 2013


On Tue, Oct 15, 2013 at 5:55 AM, Dhiru Kholia <dhiru.kholia at gmail.com> wrote:
> On 10/15/13 at 05:30am, Josh Boyer wrote:
>> On Tue, Oct 15, 2013 at 5:19 AM, Dhiru Kholia <dhiru.kholia at gmail.com> wrote:
>> > During the development of "unSPEC" [1] benchmarking suite, I made some
>> > interesting observations regarding 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.
>
> Hi Josh,
>
> Good points.
>
> Please see http://lwn.net/Articles/341244/ page. In particular, "Note,
> also small but frequently used apps benefit. I run gcc etc a lot and
> like every single saved cycle."
>
> I just wanted to quantify these kinds of use-cases too. Does this make
> sense?

Sure, if you take the "save every cycle I can approach".  It's all
relative to your point of view.  I was just noting that a common
Fedora user wouldn't necessarily expect prelink to help with
compilation times.  Even a crazy kernel developer like me doesn't
expect that.  I can be very impatient when it comes to dealing with
machines, but even I can't notice 250ms ;).

josh


More information about the devel mailing list