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?
