I reported that:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=82032
Pádraig.
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
On Fri, 8 Oct 2004, Mike Westall wrote:
>Thanks for replying, but I was complaining
>about the performance of
>
><>
>
>and not grep. Does the same disease afflict
>both
Sorry, my mistake; it is the same disease though, and I think this
describes the problem you're seeing:
http://bugzilla.red
Thanks, I'll try the official code out.
the LC_ALL=C appeared to make no diff.
Its not a critical problem to me since the RH 7.2 sort
works just fine on the RH 9.0 systems.
RH-9.0 has been out so long I was amazed that a google
search of for redhat sort performance yielded no hits.
Maybe no one
On Fri, 8 Oct 2004, Mike Westall wrote:
>The file fack.0-1.dif is an ASCII text file of 54,853 lines
>with 4 columns of numeric data. I noticed very slow performance
>when trying to sort on a RH9.0 system:
Stop right there - Unicode problems. See:
http://rhn.redhat.com/errata/RHBA-2004-083.html
Thanks for replying, but I was complaining
about the performance of
<>
and not grep. Does the same disease afflict
both
On Fri, 8 Oct 2004, Mike Westall wrote:
>>The file fack.0-1.dif is an ASCII text file of 54,853 lines
>>with 4 columns of numeric data. I noticed very slow performance
>>whe
Mike Westall <[EMAIL PROTECTED]> writes:
> Any ideas whats up with this
What happens when you compile and use the latest stable coreutils
release instead? That way, we can try to isolate whether your problem
is specific to Red Hat's changes to "sort".
ftp://ftp.gnu.org/gnu/coreutils/coreuti
The file fack.0-1.dif is an ASCII text file of 54,853 lines
with 4 columns of numeric data. I noticed very slow performance
when trying to sort on a RH9.0 system:
projects/nettraf/sriram/traces0 ==> time sort -n -k2 < fack.0-1.dif >
junk.srt
real7m42.905s
user7m42.650s
sys 0m0.090s
