4 ms·

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.

by dastx 6y ago

Blikkentrekker 6y ago
GNU coreutils are quite fast by the way. https://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html 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.
- codethief 6y ago
  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 https://github.com/BurntSushi/ripgrep and https://blog.burntsushi.net/ripgrep/ https://blog.burntsushi.net/ripgrep/ .
  - duckerude 6y ago
    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).
  - arp242 6y ago
    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.
  - rcxdude 6y ago
    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.
  - burntsushi 6y ago
    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.

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.

by dastx 6y ago

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.

Blikkentrekker 6y ago

GNU coreutils are quite fast by the way. https://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html 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.

codethief 6y ago
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 https://github.com/BurntSushi/ripgrep and https://blog.burntsushi.net/ripgrep/ https://blog.burntsushi.net/ripgrep/ .
- duckerude 6y ago
  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).
- arp242 6y ago
  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.
- rcxdude 6y ago
  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.
- burntsushi 6y ago
  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.