3 ms·
Since the article emphasizes performance so much, I’d have liked to see some benchmarking of the new core utils against the old, instead of the questionable and
by ummonk 1y ago
Since the article emphasizes performance so much, I’d have liked to see some benchmarking of the new core utils against the old, instead of the questionable and unsourced claim that “So far benchmarks have shown time and time again that at best with a lot of optimizations and tweaks Rust can only ever match the performance of C and in most cases it is actually slower.”
- oguz-ismail 1y ago> I’d have liked to see some benchmarking of the new core utils against the old, Are they compatible enough yet? Last time I checked uutils wasn't honoring user locales at all.
- nenenejej 1y agoYes cat, top and ls not being fast enough is driving me nuts. /s
- theryangeary 1y agoIn the past few days I've been benchmarking my own tool `choose` against BSD cut, GNU cut, and uutils cut and the uutils cut is certainly faster than BSD or GNU versions: https://github.com/theryangeary/choose/blob/master/benchmarking.md https://github.com/theryangeary/choose/blob/master/benchmark...
- pixelbeat__ 1y agoThe benchmark is against unibyte text. You would get more accurate results by doing `export LC_ALL=C` in your benchmark script
- theryangeary 1y agoI tried adding LC_ALL=C as well as LC_ALL=en_US.UTF-8 and it didn't make much of a difference outside of BSD cut[0]. The input file to the benchmark is all ASCII text chars (unibyte?) and `choose` does take the safe(r?) route and assume all text is UTF-8 and handle accordingly. 0: | LC_ALL=C | LC_ALL=en_US.UTF-8 | not setting LC_ALL explicitly ------------------------------------------------------------------- choose | 110.6 ms | 110.6 ms | 110.8 ms cut | 813.9 ms | 983.9 ms | 971.7 ms gcut | 172.8 ms | 172.5 ms | 174.0 ms ucut | 78.22 ms | 79.39 ms | 79.38 ms