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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
