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:
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.)
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.
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.
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|4 months ago
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|4 months ago
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|4 months ago
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):
`ugrep` actually does a lot better if you don't ask it to respect gitignore files: 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:
mort96|4 months ago
opan|4 months ago
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.
unknown|4 months ago
[deleted]