3 ms·
Optimized grep is as fast as the non optimized grep. Seems odd. I've seen ripgrep (in Rust, also by article contributor Andrew Gallant aka burntsushi) outperfo
by cies 6y ago
Optimized grep is as fast as the non optimized grep. Seems odd.
I've seen ripgrep (in Rust, also by article contributor Andrew Gallant aka burntsushi) outperform grep in almost every way possible, both in benchmarks and in my experience.
- burntsushi 6y agoI think grep (and wc) are included in that table as a sort of baseline. Like, "roughly speaking, what can we expect?" Or maybe, "what can we hope for?" grep (or ripgrep) isn't otherwise particularly relevant here. In the case of grep and wc, the "optimized" variant is running with LC_ALL=C, which sets the locale to C. Presumably, the non-optimized variant is using the OP's default locale, which is maybe something like en_US.UTF-8. (Apologies for the US assumption, but what matters is that it's not the C locale.) This is a common trick for speeding up GNU utilities when you're only working with ASCII data. It also works for things like `sort`. In the case of grep, sometimes running with and without the locale will be about as fast, particularly if you're only searching for a simple ASCII literal pattern.
- rtb 6y agoThe "grep" and "wc" commands that are included in that table don't attempt to solve the problem. That wasn't clear to me on first reading. I suppose they are included as a baseline for reading a file and for tokenising strings into words. See https://github.com/benhoyt/countwords/blob/eb2a8adf21c895907a7abd14a66650eb1f83c1a4/benchmark.py#L23 https://github.com/benhoyt/countwords/blob/eb2a8adf21c895907...