prelink performance gains

[Dhiru Kholia]

On 10/17/13 at 03:48pm, Jan Kratochvil wrote:
> Here is another measurement.  I do not agree with the initial post's approach
> as (1) It flushes disk cache.  That has no meaning for prelink measurement, it
> just adds more fuzziness to the results and it is even unreal representation
> of real world use cases.  (2) It runs big end-user GUI application.  This adds
> various interactions with X and the applications has its own heavy startup
> cost, it all also adds fuzziness to the results.  (3) When we look at global
> GNU/Linux market its end user deployment (*Office) is not relevant, server
> side execution matters.  => It all seems to me as intentionally chosen just to
> prove prelink gain is not measurable.
>
> Therefore I made IMO a more real world measurement with: time gdb/configure
> ...

<kidding>

Hopefully, you are not building fresh GCC (and other big applications)
on your *production* servers. If yes, we need to have a private talk ;)

</kidding>

> To make clear why such test matters.  Running configure scripts has become the
> major builds bottleneck in recent days as it cannot be parallelized on
> multicore and multinode machines.  For GDB it takes now 56% (of 1m37.380s) of
> the whole compilation time.  And be sure developers are running configure by
> orders of magnitude more times than *Office (or even LaTeX).

I too face this problem on a regular basis. I guess that a lot of folks
will agree that "configure just sucks in modern times".

Here is my workaround, "yum install ccache". It works great for the
projects I work on.

--
Dhiru