>> 2.61 10.0sec 1037568 bytes
>> 2.62 7.0sec 1057356 bytes
>> 2.63 7.5sec 1058211 bytes
>> 2.63+funcs 6.0sec 742044 bytes
>> git 4.6sec 744144 bytes
>>
>
> Yes, it is! Could you denote whether that is autoconf run time or
> configure run time, and also post a column for the missing of the two?
It is autoconf run time; the autoconf run time is also interesting
because I did see a marked improvement in `make check' time for Autoconf
itself (and it should be there for Automake and Libtool too).
But here are the numbers (this is Darwin).
2.61 user 0m42.634s + sys 1m38.910s
2.62 user 0m40.131s + sys 1m33.438s
2.63 user 0m40.663s + sys 1m35.434s
git user 0m38.568s + sys 1m25.364s (including my last pending patch)
4.6 seconds for configure run time is simply a dream, at least on this
system. :-)
So there is anyway a 13% improvement, probably much more on Cygwin,
maybe a bit less on Linux; not stellar but interesting anyway.
I got some more numbers on Darwin (f is a function holding only :):
time for i in `seq 1 10000`; do : 0m0.218s + 0m0.015s
time for i in `seq 1 10000`; do {:;} 0m0.218s + 0m0.010s
time for i in `seq 1 10000`; do f 0m0.426s + 0m0.029s
time for i in `seq 1 10000`; do test -f f.c 0m0.373s + 0m0.087s
time for i in `seq 1 10000`; do test a = b 0m0.374s + 0m0.040s
time for i in `seq 1 10000`; do : > foo 0m0.507s + 0m0.536s
time for i in `seq 1 1000`; do (exit 0) 0m0.850s + 0m5.625s
time for i in `seq 1 1000`; do /sw/bin/true 0m1.635s + 0m7.971s
time for i in `seq 1 1000`; do (/sw/bin/true) 0m1.745s + 0m7.971s
time for i in `seq 1 1000`; do /sw/bin/true >&2 0m1.619s + 0m8.067s
time for i in `seq 1 1000`; do /sw/bin/true >foo 0m1.713s + 0m8.693s
and on Linux:
time for i in `seq 1 10000`; do : 0m0.236s + 0m0.008s
time for i in `seq 1 10000`; do {:;} 0m0.228s + 0m0.004s
time for i in `seq 1 10000`; do f 0m0.588s + 0m0.028s
time for i in `seq 1 10000`; do : > foo 0m0.568s + 0m0.304s
time for i in `seq 1 10000`; do test -f f.c 0m0.416s + 0m0.092s
time for i in `seq 1 10000`; do test a = b 0m0.400s + 0m0.064s
time for i in `seq 1 1000`; do (exit 0) 0m1.144s + 0m3.452s
time for i in `seq 1 1000`; do /bin/true 0m0.944s + 0m2.692s
time for i in `seq 1 1000`; do (/bin/true) 0m1.400s + 0m3.368s
time for i in `seq 1 1000`; do /bin/true >&2 0m1.048s + 0m2.752s
time for i in `seq 1 1000`; do /bin/true >foo 0m1.212s + 0m3.076s
both on Bash 3.2. Based on this here are some interesting things:
1) this looks like a bug in Bash (it stops growing after a while, at least):
$ time for i in `seq 1 4000`; do (/bin/true) ; done
user 0m1.400s sys 0m3.368s
$ time for i in `seq 1 4000`; do (/bin/true) ; done
user 0m2.116s sys 0m4.192s
$ time for i in `seq 1 4000`; do (/bin/true) ; done
user 0m2.904s sys 0m4.880s
$ time for i in `seq 1 4000`; do (/bin/true) ; done
user 0m3.824s sys 0m5.920s
$ time for i in `seq 1 4000`; do (/bin/true) ; done
user 0m4.584s sys 0m5.804s
$ time for i in `seq 1 4000`; do (/bin/true) ; done
user 0m4.704s sys 0m5.868s
It may also be some problematic malloc pattern, since I can reproduce it
only on Linux systems and it comes and goes in different versions of
Bash. That would be okay because it would be less likely to affect
real-world scripts.
2) Lessons to learn are: avoid subshells (and we don't have many,
especially in code that goes in shell functions or is repeated over and
over); don't fear builtins and {...}; an `if test' can be worthwhile
even if it saves a single fork; shell functions are expensive but not
awful; redirects to files are expensive but not as much as forks, and
redirects to descriptors are extremely cheap.
Indeed look at db6098: if you really need to set $? you should use a
shell function that does "return $1", and not "(exit $var)", but maybe
"test $var != 0" suffices...
3) I haven't bisected the likely sources of speedups, but they should be
the obvious ones:
204aa09afa24abf4e54e9b407053075bbac59ef6 Remove three forks (not pushed)
8e27cc7f52924f2554d715a9ca171fe2b5d88093 Dispatch on AC_LANG_CONFTEST
db60987f02c42b4ead01b7f569f5e8c71c0ecf87 Avoid a fork
I don't know if there is more low-hanging fruit (I was especially
surprised by the AC_LANG_SOURCE hack that was probably dating back to
Autoconf 2.13 and earlier and so easy to fix), but at least there are no
more (exit)'s (there are some in Libtool) which are very expensive.
Paolo
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
