7 ms·

GNU grep is an excellent tool! A similar tool that is rising in popularity is ripgrep (https://github.com/BurntSushi/ripgrep https://github.com/BurntSushi/ripg

GNU grep is an excellent tool! A similar tool that is rising in popularity is ripgrep (https://github.com/BurntSushi/ripgrep https://github.com/BurntSushi/ripgrep), which can be orders of magnitude faster than GNU grep. Give it a try!

miguelmota 8y ago
+1 for ripgrep. It's crazy fast
- vmchale 8y ago
  It's more that it uses concurrency intelligently. The underlying stuff is similar to GNU grep.
  - OrgNet 8y ago
    > It's more that it uses concurrency intelligently if you don't do this at this point, there's a problem... because most CPUs are multicore
  - vesinisa 8y ago
    ripgrep's README has this to say about speed: > ripgrep is built on top of Rust's regex engine. Rust's regex engine uses finite automata, SIMD and aggressive literal optimizations to make searching very fast. Rust's regex library also maintains performance with full Unicode support by building UTF-8 decoding directly into its deterministic finite automaton engine.
    - cyphar 8y ago
      The author said in a sister thread[1] that for similar tasks the performance is comparable. ripgrep (and ag) both feel incredibly fast because they skip whole files and directories which are usually unwanted when searching. [1]: https://news.ycombinator.com/item?id=19523263 https://news.ycombinator.com/item?id=19523263
    - kibwen 8y ago
      Worth mentioning that the main author of ripgrep is also the main author of Rust's regex library, so their development nicely complements each other.
armitron 8y ago
In my personal tests, it's not at all orders of magnitude faster than GNU grep. In fact, for single file, non-unicode greps (most of my usage) the difference is so small as to be imperceptible when interactively using it. Even for multi-file scenarios, the difference is nowhere near close the difference between GNU grep and BSD grep. This means that compatibility with GNU grep takes priority for me and it's not worth switching over to ripgrep.
- spacesuitman2 8y ago
  For all my searches so far, ripgrep is about 30-100x faster. Perhaps you're on some hardware which ripgrep isn't well suited for.
  - rujuladanh 8y ago
    That is simply impossible. You are measuring the wrong thing or a case where rg can skip most files.
- TimTheTinker 8y ago
  There’s a reason VSCode uses ripgrep under the hood for searching. It can make a huge difference in a large (1M+ LOC) project.
  - Scarbutt 8y ago
    This "huge diffrence" is just miliseconds for a 20M LoC, as the author showed in this thread using the linux kernel source, he gives importance to the UX when compared to grep though.
    - acdha 8y ago
      Read the second half of his comment and ask what percentage of the Linux kernel source would be excluded by file type rules versus other projects. I mostly work on web and data archival projects and ripgrep is noticeably seconds (or more!) faster because it can skip images, archives, etc. If you’re talking about the core algorithm, it’s not that much faster but the clever adjustments for common patterns and modern CPU architectures also counts for real world results. It’s just important to be precise so people know there hasn’t been some fundamental breakthrough in searching.

miguelmota 8y ago

+1 for ripgrep. It's crazy fast

vmchale 8y ago
It's more that it uses concurrency intelligently. The underlying stuff is similar to GNU grep.
- OrgNet 8y ago
  > It's more that it uses concurrency intelligently if you don't do this at this point, there's a problem... because most CPUs are multicore
- vesinisa 8y ago
  ripgrep's README has this to say about speed: > ripgrep is built on top of Rust's regex engine. Rust's regex engine uses finite automata, SIMD and aggressive literal optimizations to make searching very fast. Rust's regex library also maintains performance with full Unicode support by building UTF-8 decoding directly into its deterministic finite automaton engine.
  - cyphar 8y ago
    The author said in a sister thread[1] that for similar tasks the performance is comparable. ripgrep (and ag) both feel incredibly fast because they skip whole files and directories which are usually unwanted when searching. [1]: https://news.ycombinator.com/item?id=19523263 https://news.ycombinator.com/item?id=19523263
  - kibwen 8y ago
    Worth mentioning that the main author of ripgrep is also the main author of Rust's regex library, so their development nicely complements each other.

armitron 8y ago

In my personal tests, it's not at all orders of magnitude faster than GNU grep. In fact, for single file, non-unicode greps (most of my usage) the difference is so small as to be imperceptible when interactively using it. Even for multi-file scenarios, the difference is nowhere near close the difference between GNU grep and BSD grep. This means that compatibility with GNU grep takes priority for me and it's not worth switching over to ripgrep.

spacesuitman2 8y ago
For all my searches so far, ripgrep is about 30-100x faster. Perhaps you're on some hardware which ripgrep isn't well suited for.
- rujuladanh 8y ago
  That is simply impossible. You are measuring the wrong thing or a case where rg can skip most files.
TimTheTinker 8y ago
There’s a reason VSCode uses ripgrep under the hood for searching. It can make a huge difference in a large (1M+ LOC) project.
- Scarbutt 8y ago
  This "huge diffrence" is just miliseconds for a 20M LoC, as the author showed in this thread using the linux kernel source, he gives importance to the UX when compared to grep though.
  - acdha 8y ago
    Read the second half of his comment and ask what percentage of the Linux kernel source would be excluded by file type rules versus other projects. I mostly work on web and data archival projects and ripgrep is noticeably seconds (or more!) faster because it can skip images, archives, etc. If you’re talking about the core algorithm, it’s not that much faster but the clever adjustments for common patterns and modern CPU architectures also counts for real world results. It’s just important to be precise so people know there hasn’t been some fundamental breakthrough in searching.