Sorry Paul.
The following obvious patch is needed for the memcoll change in 6.0.
I didn't notice it in my quick test as I had forgotten I changed
xmemcoll to memcoll in uniq in my tree.
I only noticed errno being non zero for me when I redirect uniq to >/dev/null
but I guess there are a million other platform/invocation combinations
that will trigger this.
Note in glibc-2.3.5-10 at least, each errno access is a function call,
but it's performance is not as bad as I first thought.
I was misled by what seems to be a best resolution in `ltrace -c` of 20µs
(on my pentium-m + kernel-2.6.16-1.2111_FC4 system at least).
The function call overheads do add up though.
For my test case of 354,371 mostly similar lines mentioned previously,
calling memcoll() directly from uniq instead of xmemcoll(),
and removing the errno accesses from memcoll(), changes the
runtime from 0.320s to 0.288s.
--- memcoll.c 2006-08-14 21:17:25.000000000 +0000
+++ memcoll-errno.c 2006-08-16 06:50:28.000000000 +0000
@@ -43,7 +43,10 @@
the buffers using strcoll on each substring. */
if (s1len == s2len && memcmp (s1, s2, s1len) == 0)
- diff = 0;
+ {
+ diff = 0;
+ errno = 0;
+ }
else
{
char n1 = s1[s1len];
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
