Thanks for the heads-up. Even without looking at the actual bug report, I admit that this is probably a good opportunity for optimization. Of course, it'd be a trade-off (memory for speed), but it sounds reasonable. If you dive in, be sure to use the latest test release (available soon): ftp://alpha.gnu.org/gnu/fetish/textutils-2.0.11.tar.gz Jason Bucata <[EMAIL PROTECTED]> wrote: | This is regarding GNU sort in textutils 2.0, as distributed in Debian potato | and woody (if that makes a difference). | | I was poking through Debian bug reports, when I noticed bug 62803 which says | that sort is too slow for non-C locales. It was put under libc6 since (it | was asserted) the only way to speed up sorting was to speed up strcoll--you | can't get the blazing speed of strcmp outside the C locale. | | Is there some reason why strxfrm can't be used here? It seems like a | perfect application of strxfrm, if you compute the strxfrm'd values for each | of the keys once (or once each time the line is read from a tempfile), cache | them in a linked list off of struct line, and compare those in your main | sort routine with ludicrous speed. | | Just for grins I started tinkering with the source (dontcha just love being | able to do that? ;) ) to see if I could make it do just that, but at 2 AM | local time it's more effort than I want to sink into it. Besides, I | figured there had to be a legitimate reason why that hasn't been done yet, | since there are plenty of great minds looking at this source. | | So then, Enquiring Minds Want To Know(TM). | | Jason B. _______________________________________________ Bug-textutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-textutils
