Hacker News Reader

Comment by dastx | Hacker News Reader

I'd love to know too. It seems like it's nearly at feature parity but if performance is an issue, it's not really a replacement.

View on HN

GNU coreutils are quite fast by the way.

https://lists.freebsd.org/pipermail/freebsd-current/2010-Aug...

This is an interesting article that outlines why GNU grep outperforms almost any other grep quite significantly, at the cost of more memory.

That statement surprises me because my impression had always been that GNU grep is rather slow compared to other (more modern) tools, see e.g. the benchmarks on https://github.com/BurntSushi/ripgrep and https://blog.burntsushi.net/ripgrep/ .

GNU grep is so fast that it set the bar for later implementations.

In your second link ripgrep is even marketed as having "the raw performance of GNU grep" (though it managed to exceed it).

When that was written in 2010 it probably was the fastest grep. It's not like GNU grep is completely devoid of any performance optimisations.

It's a bit out of date (that email predates ripgrep). ripgrep goes even further in terms of skipping work, as well as focusing on parallelism.

Look at the dates on the material you're reading. That should resolve most of your confusion.

Also, to be clear, in a strict apples to apples comparison, GNU grep and ripgrep will tend to have comparable performance. ripgrep does edge it out a bit in many cases, but it isn't always earth shattering. However, if you don't limit yourself to apples-to-apples comparisons and instead look at the user experience, then yes, ripgrep will likely be "a lot" faster. Primarily because of automatic parallelism and its "smart" filtering.

Reply on news.ycombinator.com