Re: some numbers

[Paolo Bonzini]

>> 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