8 ms·

shoutout to [RipGrep](https://github.com/BurntSushi/ripgrep https://github.com/BurntSushi/ripgrep), which is generally faster, has more intelligent defaults (se

shoutout to [RipGrep](https://github.com/BurntSushi/ripgrep https://github.com/BurntSushi/ripgrep), which is generally faster, has more intelligent defaults (searches cwd by default, ignores files matching .gitignore), and can search through only certain text files (like your .java and .py files, say). Not affiliated, just found it worth the effort to learn some slightly different flags, though many are the same as normal grep.

yencabulator 7y ago
Shoutout to git grep. I use `git grep -n -E --untracked` (via a small wrapper) a lot more than I use ripgrep. It's even faster than ripgrep for me.
- burntsushi 7y ago
  I'm always looking for new benchmarks. :) Do you have any easily accessible examples where git grep is materially faster than ripgrep? If not that's cool. Thanks!
freedomben 7y ago
Also a ripgrep fan. I rolled my own search tool[1] due to dissatisfaction with the available options at the time, but I gave ripgrep an evaluation when it came out and it was really good. I ultimately still use my own tool because I'm very attached to the way grep colors/formats stuff (and I implemented the same scheme in findref) but I use ripgrep on large code bases (like the Linux kernel) since it performs a lot better due to various optimizations. [1] https://github.com/FreedomBen/findref https://github.com/FreedomBen/findref
- burntsushi 7y ago
  Small note: if you want ripgrep's output to match grep's, then you can do alias rg="rg --no-heading" It will still show file paths and line numbers. Those can be disabled too, with `rg --no-heading --no-line-number --no-filename`.
  - freedomben 7y ago
    oh neat, thank you!
abrowne 7y ago
IIRC VS Code also uses ripgrep internally for searching.
ainar-g 7y ago
> ignores files matching .gitignore Maybe it's just me, but that sounds like a bad default. I can definitely imagine people being confused by that.
- choeger 7y ago
  It is. At first. But you get used to it quite fast. In my experience, when I have a .gitignore I either want to grep the ignored stuff or the rest, never both. So I notice quite early that something is odd, when rg reports nothing at all.
- Terr_ 7y ago
  A problem-scenario that comes to mind involves "set your own" config files, like when a codebase has a config.xml.dist and you're supposed to copy and customize it to config.xml which should never get checked in.
- burntsushi 7y ago
  They are. That's why it's always mentioned in the first few sentences of docs (man page, --help, README). With that said, this default is one of ripgrep's defining features and is something that users consistently report as one of their favorite things about ripgrep. You can disable all smart filtering (gitignore, hidden, binary) with `rg -uuu foo`. That will search the same stuff that `grep -r foo ./` will.
- dmurray 7y ago
  It's less confusing if you think of it as a code search tool, rather a text search tool. Though now I realise how useful I would find this feature.
2038AD 7y ago
I've not looked too far into it but my guess is that ripgrep being faster is just due to Gnu grep using a slower algorithm (and supporting unnecessary extensions). The Rust regex library excludes look-arounds and backreferences and is openly inspired by RE2. Russ Cox, one of the guys behind RE2, wrote something[0] on the topic. [0] https://swtch.com/~rsc/regexp/regexp1.html https://swtch.com/~rsc/regexp/regexp1.html
- burntsushi 7y ago
  No, that's not why. I wrote about why: https://blog.burntsushi.net/ripgrep/ https://blog.burntsushi.net/ripgrep/ GNU grep doesn't have look-arounds either. It does have back-references, but that doesn't impact searches that don't use back-references. I don't think there is really a concise way to describe why ripgrep is faster when comparing apples-to-apples. It depends on the queries and the corpus. The primary reasons are that it makes more efficient use of the hardware with algorithms that utilize SIMD. If you do an apples-to-oranges comparison (i.e., "why is `rg foo ./` so much faster than `grep -r foo ./`), then the answer is pretty easily "because ripgrep uses parallelism and employs smart filtering by default."
  - pjot 7y ago
    Genuinely curious how you noticed that this thread had referenced your work. And, ironically enough, a thread about text search!
    - burntsushi 7y ago
      For this thread, I just saw a thread that mentioned grep. At that point, I naturally gravitate toward it since I'm obviously very interested in the topic!
      - pjot 7y ago
        Pretty cool coincidence nonetheless! The reason I asked was because I noticed that your comment was within minutes of the parent comment which was a response to another comment about _your_ text-search project and how fast it is. I said out loud, "Wow" and browsed through ripgrep. Nice work! Was torn on whether you were tailing the HN api with ripgrep to alert you or if it was just the right place and time. I had a good time going through how that would work, so, thank you haha! Occam's razor, right?

yencabulator 7y ago

Shoutout to git grep. I use `git grep -n -E --untracked` (via a small wrapper) a lot more than I use ripgrep. It's even faster than ripgrep for me.

burntsushi 7y ago
I'm always looking for new benchmarks. :) Do you have any easily accessible examples where git grep is materially faster than ripgrep? If not that's cool. Thanks!

freedomben 7y ago

Also a ripgrep fan. I rolled my own search tool[1] due to dissatisfaction with the available options at the time, but I gave ripgrep an evaluation when it came out and it was really good. I ultimately still use my own tool because I'm very attached to the way grep colors/formats stuff (and I implemented the same scheme in findref) but I use ripgrep on large code bases (like the Linux kernel) since it performs a lot better due to various optimizations. [1] https://github.com/FreedomBen/findref https://github.com/FreedomBen/findref

burntsushi 7y ago
Small note: if you want ripgrep's output to match grep's, then you can do alias rg="rg --no-heading" It will still show file paths and line numbers. Those can be disabled too, with `rg --no-heading --no-line-number --no-filename`.
- freedomben 7y ago
  oh neat, thank you!

abrowne 7y ago

IIRC VS Code also uses ripgrep internally for searching.

ainar-g 7y ago

> ignores files matching .gitignore Maybe it's just me, but that sounds like a bad default. I can definitely imagine people being confused by that.

choeger 7y ago
It is. At first. But you get used to it quite fast. In my experience, when I have a .gitignore I either want to grep the ignored stuff or the rest, never both. So I notice quite early that something is odd, when rg reports nothing at all.
Terr_ 7y ago
A problem-scenario that comes to mind involves "set your own" config files, like when a codebase has a config.xml.dist and you're supposed to copy and customize it to config.xml which should never get checked in.
burntsushi 7y ago
They are. That's why it's always mentioned in the first few sentences of docs (man page, --help, README). With that said, this default is one of ripgrep's defining features and is something that users consistently report as one of their favorite things about ripgrep. You can disable all smart filtering (gitignore, hidden, binary) with `rg -uuu foo`. That will search the same stuff that `grep -r foo ./` will.
dmurray 7y ago
It's less confusing if you think of it as a code search tool, rather a text search tool. Though now I realise how useful I would find this feature.

2038AD 7y ago

I've not looked too far into it but my guess is that ripgrep being faster is just due to Gnu grep using a slower algorithm (and supporting unnecessary extensions). The Rust regex library excludes look-arounds and backreferences and is openly inspired by RE2. Russ Cox, one of the guys behind RE2, wrote something[0] on the topic. [0] https://swtch.com/~rsc/regexp/regexp1.html https://swtch.com/~rsc/regexp/regexp1.html

burntsushi 7y ago
No, that's not why. I wrote about why: https://blog.burntsushi.net/ripgrep/ https://blog.burntsushi.net/ripgrep/ GNU grep doesn't have look-arounds either. It does have back-references, but that doesn't impact searches that don't use back-references. I don't think there is really a concise way to describe why ripgrep is faster when comparing apples-to-apples. It depends on the queries and the corpus. The primary reasons are that it makes more efficient use of the hardware with algorithms that utilize SIMD. If you do an apples-to-oranges comparison (i.e., "why is `rg foo ./` so much faster than `grep -r foo ./`), then the answer is pretty easily "because ripgrep uses parallelism and employs smart filtering by default."
- pjot 7y ago
  Genuinely curious how you noticed that this thread had referenced your work. And, ironically enough, a thread about text search!
  - burntsushi 7y ago
    For this thread, I just saw a thread that mentioned grep. At that point, I naturally gravitate toward it since I'm obviously very interested in the topic!
    - pjot 7y ago
      Pretty cool coincidence nonetheless! The reason I asked was because I noticed that your comment was within minutes of the parent comment which was a response to another comment about _your_ text-search project and how fast it is. I said out loud, "Wow" and browsed through ripgrep. Nice work! Was torn on whether you were tailing the HN api with ripgrep to alert you or if it was just the right place and time. I had a good time going through how that would work, so, thank you haha! Occam's razor, right?