bug#6789: propose renaming gnulib memxfrm to amemxfrm (naming collision with coreutils)

[Paul Eggert]

On 08/03/10 16:33, Bruno Haible wrote:
> But when the stack buffer is not sufficient, then the use of coreutils memxfrm
> is 30% to 70% slower than the use of gnulib memxfrm, with a difference of
> 700 μsec at least.

(Ooo!  Ooo!  Performance measurements!  I love this stuff!)

It depends on the data.  In the typical case, "sort" is applied to
text data, which does not contain NUL bytes.  The data in that
benchmark contained many NUL bytes.  If you take the same benchmark
and uniformly replace "\0" with "\t" in compare.c, then the situation
is much different: coreutils memxfrm is about 3 times faster than
gnulib memxfrm on the larger test cases (this platform is Ubuntu
10.04, gcc 4.5.0, 2.4 GHz Pentium 4):

  503-penguin $ gcc -std=gnu99 -O2 -Wall coreutils-memxfrm.c gnulib-memxfrm.c 
compare1.c -I.
  504-penguin $ ./a.out
  Time for gnulib_memxfrm: 0,032002
  Time for coreutils_memxfrm: 0,028001
  Time for gnulib_memxfrm: 0,024002
  Time for coreutils_memxfrm: 0,024001
  Time for gnulib_memxfrm: 0,036003
  Time for coreutils_memxfrm: 0,032002
  Time for gnulib_memxfrm: 18,2051
  Time for coreutils_memxfrm: 5,48834
  Time for gnulib_memxfrm: 16,045
  Time for coreutils_memxfrm: 5,50034
  Time for gnulib_memxfrm: 15,837
  Time for coreutils_memxfrm: 5,44834

I expect that this performance glitch in gnulib memxfrm could be
improved, as it shouldn't simply double buffer sizes when they're too
small, as at that point it already knows what the final buffer size
should be.  Doing this should bring up gnulib memxfrm to be as fast as
coreutils xmemxfrm for this benchmark.  Also, I agree that gnulib
memxfrm is faster in some important cases.  Still, gnulib memxfrm is
problematic, because it insists on managing memory itself.

Come to think of it, looking at gnulib memxfrm gave me an idea
to improve the performance of GNU sort by bypassing the need for an
memxfrm-like function entirely.  I pushed a patch to do that at
<http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=2b49b140cc13cf36ec5ee5acaca5ac7bfeed6366>.

This avoids any potential naming collision for now.  The point
remains, though, that it's confusing that gnulib memxfrm's name begins
with "mem", as the mem* functions don't allocate memory.  Would you
consider a patch that renames gnulib memxfrm to amemxfrm, or to some
other such name?