bug#32099: Testing with other options (Was: Benchmarks: Hashing ~70% faster )

2018-07-13 Thread Kingsley G. Morse Jr.
Hey Berny, I like your suggestion of testing whether hashing interferes with any other option. I was glad to see the POSIX standard doesn't explicitly require sorted input or output. If someone writes the patch, I should be able to test it, at least on up to 1 GB of input. So, Kingsley On 07/1

bug#32099: datamash wins! (Was: New uniq option for speed)

2018-07-11 Thread Kingsley G. Morse Jr.
. So it is done. Sorting is great, but less is number one! ~K PS: Congratulations on datamash performing so well. On 07/10/2018 12:21, Assaf Gordon wrote: > tag 32099 notabug > severity 32099 wishlist > close 32099 > stop > > Hello Kingsley, > > On 09/07/18 10:2

bug#32099: Benchmarks: Hashing ~70% faster (Was: New uniq option for speed)

2018-07-09 Thread Kingsley G. Morse Jr.
o be faster and free from sort. Feel free to let me know if I screwed up. Thanks, Kingsley On 07/09/2018 14:53, Assaf Gordon wrote: > Ηello, > > On 08/07/18 03:03 PM, Kingsley G. Morse Jr. wrote: > > The main reason I'm writing is to humbly suggest > > a performance

bug#32101: New uniq option for speed

2018-07-08 Thread Kingsley G. Morse Jr.
For what it's worth, I use version 8.28-1 of Debian's coreutils package. Thanks, Kingsley -- Time is the fire in which we all burn.

bug#32099: New uniq option for speed

2018-07-08 Thread Kingsley G. Morse Jr.
Thank you very much for maintaining coreutils! It seems to me that it would be hard to underestimate how useful it is. The main reason I'm writing is to humbly suggest a performance improvement to the "uniq" command. It currently requires its input to be sorted. Sorting generally takes about O