Re: poor m4 hash performance

[Paul Eggert]

address@hidden (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.