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