Re: --localdir backwards compatibility

[Niels Möller]

Akim Demaille <address@hidden> writes:

> Slowness is relative: the more you run it, the less it is, precisely
> thanks to the cache.  That's a dramatic speed up when using autoheader
> and/or automake.

Not compared to autoconf-2.13. So let's leave the backwards
compatibility question for now and talk a little about slowness.

Compared to autoconf-2.13, current autoconf is really, really slow.
Ok, on my 2 GHz PC at work it doesn't matter very much, but it's quite
painful on my home machine (an old sparc station, 110 bogomips, which
is adequate for most hacking I do).

To get some numbers, I just downloaded the old autoconf-2.13. For a
testcase, I use the configure script for adns-1.0, slightly hacked so
that it works with both old and new autoconf. This is a fairly
simple configure script of 150 lines. Some timings:

First run with autoconf-2.57, no autom4te.cache:

  real  0m50.642s
  user  0m38.650s
  sys   0m9.710s

Second run, using the autom4te.cache:

  real  0m17.839s
  user  0m7.540s
  sys   0m8.850s

Third run, using the old autoconf-2.13:

  real  0m2.602s
  user  0m0.990s
  sys   0m1.370s

About half of this difference (2.13 vs 2.57 with cache) is probably
startup time,

  $ time autoconf --version
  autoconf (GNU Autoconf) 2.57
  Written by David J. MacKenzie and Akim Demaille.
  [...]
  
  real  0m7.012s
  user  0m0.510s
  sys   0m6.270s

  $ time automake --version
  automake (GNU automake) 1.7.3
  Written by Tom Tromey <address@hidden>.
  [...]
  
  real  0m9.529s
  user  0m7.090s
  sys   0m0.730s

  $ time /usr/local/traditional/bin/autoconf --version
  Autoconf version 2.13
  
  real  0m0.672s
  user  0m0.140s
  sys   0m0.390s

So even with the cache, the modern autoconf is about an order of
magnitude slower. Note that I can run the old autoconf (or autoheader,
assuming it takes about the same cpu cycles) *20 times* during the
time it takes to create autom4te.cache. I don't run autoconf and
autoheader that many times between configure.in changes, so it seems
the time spent building the cache doesn't pay off.

When I installed autoconf-2.57 running make took about 20-30 *hours*.
That's about the same time it takes to build gcc from scratch,
including the C++ and java libraries (the bootstrap C compiler proper
takes just an hour or two, iirc).

I like the modern autoconf, but the slowdown *is* painful enough that
I have no problem understanding that people hesitate before upgrading
to autoconf-2.57.

To me, autom4te.cache looks a lot like a mistake. On fast machines, it
doesn't matter very much, and on slower machines like mine, the time
spent building the cache appearantly doesn't pay off at all. And then
you also get additional complexity, and the perl dependency (which
matters to some people, most of which probably uses only autoconf, not
automake).

Best regards,
/Niels