[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

just how much autotools got faster, or: just forget about dolt

From: Ralf Wildenhues
Subject: just how much autotools got faster, or: just forget about dolt
Date: Sun, 23 Nov 2008 15:51:53 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

For all dolt junkies, and whoever claims autotools and esp. libtool
are performance hogs: yes, they are still not the fastest thing in
the world.  But we are getting better:

As an example, I built the ompi/ subdirectory of OpenMPI on a two-way
GNU/Linux system using bash, with
1) Autoconf 2.61, Automake 1.10.1, Libtool 1.5.26,
2) git master versions of same tools,

a) a full 'make -j3',
b) measuring just build system overhead, which in case of (2) is pretty
well approximated with
    \time make -k -j3 LIBTOOLFLAGS=-n am__mv=:
and in case of (1) involves placing a fake 'mv' program early in $PATH.

Here's the results:

297.74user 98.61system 4:10.10elapsed 158%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+184024outputs (0major+44783943minor)pagefaults 0swaps
66.47user 66.34system 1:36.46elapsed 137%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+16outputs (0major+34664638minor)pagefaults 0swaps
259.43user 40.33system 3:15.70elapsed 153%CPU (0avgtext+0avgdata 0maxresident)k
2160inputs+166264outputs (9major+13717764minor)pagefaults 0swaps
29.05user 7.13system 0:33.91elapsed 106%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+16outputs (0major+2959788minor)pagefaults 0swaps

What does this mean?  Going from (1) to (2) gives 22% saving in absolute
build time.  Meanwhile, the build system overhead (time not spent inside
gcc, ar, ld) went from 38% of the total build time down to 17%.  That's
not yet the 5% which Bob once decreed as goal, but also it's not too far
away any more.  I think we can be pretty proud of being able to cut 65%
off the build system overhead.  :-)

I especially like how the system time of the overhead went from 66s to
7s, meaning that relative savings on w32 systems are likely going to be
even higher.  Of course, that being only 3.5% of the total overhead now,
that also means that we won't be able to shave off a lot more by merely
reducing the number of forks (forks add mostly system time).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]