GNU bug report logs -
#6789
propose renaming gnulib memxfrm to amemxfrm (naming collision with coreutils)
Previous Next
Reported by: Paul Eggert <eggert <at> CS.UCLA.EDU>
Date: Tue, 3 Aug 2010 19:47:01 UTC
Severity: normal
Done: Jim Meyering <jim <at> meyering.net>
Bug is archived. No further changes may be made.
Full log
Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):
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?
This bug report was last modified 14 years and 6 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.