Has it caught up to ugrep in terms of backward compatibility and speed yet?

▲ burntsushi 15 hours ago | parent | next [-]

Backcompat with what? ripgrep was, is and will never be POSIX compatible: https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#can...

Aa for ugrep, flipping the question around would be more appropriate. ugrep has caught up with ripgrep in some common cases, but not all.

▲ dgacmu 15 hours ago | parent | prev | next [-]

This seems like an unhelpful comment?

First of all, the ugrep performance comparisons are online (and haven't been updated to compare against this version that was only released 3 days ago). So your question is answerable:

https://github.com/Genivia/ugrep-benchmarks

The two are very close and both are head and shoulders faster than most other options.

And backwards compatibility is a mixed thing, not a mandatory goal. It's admirable that ugrep is trying to be a better drop-in replacement. It's also cool that ripgrep is trying to rethink the interface for improving usability.

(I like ripgrep in part because it has different defaults than grep that work very well for my use cases, which is primarily searching through codebases. The lack of backwards compatibility goes both ways. Will we see a posix ripgrep? Probably not. Is ripgrep a super useful and user-friendly tool? Definitely.)

▲ burntsushi 13 hours ago | parent | prev | next [-]

To back up what I said earlier, a common case for ripgrep is to search a code repository while respecting gitignore, ignoring hidden files and ignoring binary files. Indeed, this is ripgrep's default mode.

For example, in my checkout of the Chromium repository, notice how much faster ripgrep is at this specific use case (with the right flags given to `ugrep` to make it ignore the same files):

    $ hyperfine --output pipe 'rg Openbox' 'ugrep-7.5.0 -rI --ignore-files Openbox ./'
    Benchmark 1: rg Openbox
      Time (mean ± σ):     281.0 ms ±   3.6 ms    [User: 1294.8 ms, System: 1977.6 ms]
      Range (min … max):   275.9 ms … 286.8 ms    10 runs

    Benchmark 2: ugrep-7.5.0 -rI --ignore-files Openbox ./
      Time (mean ± σ):      4.250 s ±  0.008 s    [User: 4.683 s, System: 2.154 s]
      Range (min … max):    4.242 s …  4.267 s    10 runs

    Summary
      rg Openbox ran
       15.12 ± 0.19 times faster than ugrep-7.5.0 -rI --ignore-files Openbox ./

`ugrep` actually does a lot better if you don't ask it to respect gitignore files:

    $ hyperfine --output pipe 'rg -u Openbox' 'ugrep-7.5.0 -rI Openbox ./'
    Benchmark 1: rg -u Openbox
      Time (mean ± σ):     233.9 ms ±   3.3 ms    [User: 650.4 ms, System: 2081.6 ms]
      Range (min … max):   228.8 ms … 239.8 ms    12 runs

    Benchmark 2: ugrep-7.5.0 -rI Openbox ./
      Time (mean ± σ):     605.4 ms ±   6.4 ms    [User: 1104.1 ms, System: 2710.8 ms]
      Range (min … max):   596.1 ms … 613.9 ms    10 runs

    Summary
      rg -u Openbox ran
        2.59 ± 0.05 times faster than ugrep-7.5.0 -rI Openbox ./

Even ripgrep runs a little faster. Because sometimes matching gitignores takes extra time. More so, it seems, in ugrep's case.

Now ugrep is perhaps intended to be more like a POSIX grep than ripgrep is. So you could question whether this is a fair comparison. But if you're going to bring up "ripgrep catching up to ugrep," then it's fair game, IMO, to compare ripgrep's default mode of operation with ugrep using the necessary flags to match that mode.

Repository info:

    $ git remote -v
    origin  git@github.com:nwjs/chromium.src (fetch)
    origin  git@github.com:nwjs/chromium.src (push)
    $ git rev-parse HEAD
    1e57811fe4583ac92d2f277837718486fbb98252

▲ mort96 14 hours ago | parent | prev [-]

I'm so happy ripgrep has a different interface to grep. I don't typically need ripgrep's better performance, I just use it because 'rg foo' does what I want 99% of the time while 'grep foo' does what I want 1% of the time.

▲

opan 14 hours ago | parent | next [-]

This is pretty much flipped from my experience, so I'm curious if you could expand on this. I use grep a lot to filter command output or maybe search all my txt file notes at once when I can't remember which file contained something. I use rg rarely, one example in recent memory is searching the source code for the game Barony to try to find some lesser-known console commands or behaviors (like what all drops a particular spellbook and how commonly).

Does rg work in the places grep does or is it about the type of task being done? In my examples I expect more default recursion from rg than from regular grep and I'm searching an unknown codebase with it, where as I often know my way around more or less when using regular grep.

	▲	burntsushi 13 hours ago \| parent [-]
		`some-command \| grep pattern` and `some-command \| rg pattern` both work fine. You can chain `rg` commands in a shell pipeline just like you do `grep`. What the GP is suggesting is that their most common use case for grep is recursive search. That's what ripgrep does by default. With `grep`, you need the non-POSIX `-r` flag. The other bit that the GP didn't mention but is critical to ripgrep's default behavior is that ripgrep will ignore files by default. Specifically, it respects gitignore files, ignores hidden files and ignores binary files. IMO, this is what most people mean by "ripgrep does the right thing by default." Because ripgrep will ignore most of the stuff you probably don't care about by default. Of course, you can disable this filtering easily: `rg -uuu`. This is also why ripgrep has never been intended to be POSIX compatible, despite people whinging about "backwards compatibility." That's a goal they are ascribing to the project that I have never professed. Indeed, I've been clear since the beginning that if you want a POSIX compatible grep, then you should just use a POSIX compatible grep. The existence of ripgrep does not prevent that. Indeed, before I wrote ripgrep, I had a bunch of shell scripts in my ~/bin that wrapped grep for various use cases. I had one shell script for Python projects. Another for Go projects. And so on. These wrappers specifically excluded certain directories, because otherwise `grep -r` would search them. For big git repositories, this would in particular cause it to waste not only a bunch of time searching `.git`, but it would also often return irrelevant results from inside that directory. Once I wrote ripgrep (I had never been turned on to `ack` or `ag`), all of those shell scripts disappeared. I didn't need them any more. My understanding is that many other users have this same experience. I personally found it very freeing to get rid of all my little shell wrappers and just use the same tool everywhere. (`git grep` doesn't work nearly as well outside of git repositories for example. And it has, last I checked, some very steep performance cliffs.) Some users don't like the default filtering. Or it surprises them so much that they are horrified by it. They can use `rg -uuu` or use one of the many other POSIX greps out there.

▲

14 hours ago | parent | prev [-]

[deleted]