ericblake@xxxxxxxxxxx (Eric Blake) writes:
> First, should autom4te experiment with changing the default hash
> size, using the -H option?
In principle that sounds reasonable, but please see below.
> By default, m4 1.4.4 uses a 509 bucket hash table, with no dynamic
> growth. Without a larger table, configure scripts are so complex
> that you are generating loads of collisions and extra time spent
> comparing strings. But what size would be the best trade of memory
> for speed, and how do we judge how complex the configure script is?
We can't judge in advance, but I suspect that it would be reasonable
to (say) find a value N that is the performance knee for coreutils,
and then use 10 * N. Anybody who uses Autoconf should have plenty of
memory these days. (Maybe 1000 * N would be better -- it partly
depends on what the value of N is. :-)
On the other hand, I just now did some experiments and didn't find
much of an improvement, so perhaps it's not worth the bother. Or
perhaps I wasn't measuring the right thing? This is with coreutils:
With -H9973:
535-penguin $ rm -fr *cache
536-penguin $ M4='/tmp/bin/m4 -H9973' bash -c 'time autoconf'
real 0m14.315s
user 0m14.170s
sys 0m0.140s
538-penguin $ rm -fr *cache
539-penguin $ M4='/tmp/bin/m4 -H9973' bash -c 'time autoconf'
real 0m14.357s
user 0m14.150s
sys 0m0.160s
Without -H9973:
540-penguin $ rm -fr *cache
541-penguin $ M4='/tmp/bin/m4' bash -c 'time autoconf'
real 0m14.524s
user 0m14.310s
sys 0m0.140s
542-penguin $ rm -fr *cache
543-penguin $ M4='/tmp/bin/m4' bash -c 'time autoconf'
real 0m14.474s
user 0m14.290s
sys 0m0.160s
/tmp/bin/m4 is m4 1.4.4, and this is with CVS coreutils.
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
