Re: Avoid certain spurious `testsuite' rebuilds

[Ralf Wildenhues]

* Paul Eggert wrote on Thu, Apr 06, 2006 at 05:40:26AM CEST:
> Noah Misch <address@hidden> writes:
> 
> > On my middle-aged PC running GNU/Linux, rebuilding
> > `testsuite' takes 22 seconds.
> 
> It takes 16 real seconds on my 4-year-old PC (2.4 GHz P4).  Of that,
> 15 real seconds are spent running autom4te.

More than 5 minutes on some of the systems I test.
Enough time to transfer the file through 2 ssh stages, do 2-3
edit-regenerate-test cycles on a fast system, and transfer back.
If you are working on a single macro and not its test, round-trip
time may be reduced significantly here.

> > To me, saving that 22 second delay before I can run a test case
> > after editing Autoconf sources is worth this amount of Makefile
> > pain.  What do you think?
> 
> 'make check' overall takes 13 minutes 41 seconds on my host; saving 16
> seconds would be nice if it didn't have all that timestamp gimmickry
> but I'm not sure it's worth the hassle, once you look at the big
> picture.

'make check' on AIX with /bin/sh takes more than 2 days IIRC, but only a
fraction of that with bash.  Still several hours for some other host.

> How about if we speed up autom4te instead?

I'm not convinced that is the way to go.  I usually don't care
whether something takes a tenth of a second or a second; only when
that happens often.  Large software packages seem to take forever to
bootstrap though; and I'm convinced this may be improved by killing
some nested "loops" in our macro code, where effectively some
superlinear, maybe even exponential scaling happens.  (Before the
ltsugar cleanup in CVS Libtool, a debug output of a m4 run measured
at >2GB of data, so it was doing some serious amount of copying and
parsing data just to throw it all away afterwards.)  I have not
checked whether the Autotest macros are in this category.

Surely Automake is a big offender, too, but there I have less
experience as to whether that is fixable.

Cheers,
Ralf