Ripgrep significantly slower than grep about ripgrep HOT 3 CLOSED

GNU grep can tell that its output is redirected to /dev/null and because of that it exits after the first match. (It still needs to use the exit code to report whether there was a match at all, but that's it.) If you send the output through cat then it cannot perform that optimization and ends up slightly slower than ripgrep:

$ hyperfine 'rg system rockyou.txt | cat' 'grep system rockyou.txt | cat'
Benchmark #1: rg system rockyou.txt | cat
  Time (mean ± σ):      50.4 ms ±  10.8 ms    [User: 37.6 ms, System: 14.2 ms]
  Range (min … max):    43.0 ms …  84.6 ms    34 runs
 
Benchmark #2: grep system rockyou.txt | cat
  Time (mean ± σ):      71.8 ms ±  13.3 ms    [User: 54.3 ms, System: 18.9 ms]
  Range (min … max):    60.4 ms …  97.5 ms    36 runs
 
Summary
  'rg system rockyou.txt | cat' ran
    1.42 ± 0.40 times faster than 'grep system rockyou.txt | cat'

from ripgrep.

Interesting, thanks for the explanation! Seems like I never looked at the execution time when getting an output...

from ripgrep.

Yeah @blyxxyz has it right. For hyperfine specifically, you can pass --output=pipe instead of adding | cat.

I have specifically avoided the "detect /dev/null and automatically enable -q/--quiet" optimization that GNU grep does. ripgrep could do it. It isn't hard to do. It just always seemed a little weird to me.

For simple literal searches like this, ripgrep should pretty much always be faster. ripgrep's substring search should be very nearly strictly superior to GNU grep's. If you can find a non-pathological case where GNU grep is noticeably faster (on x86-64 or aarch64) for real, I'd love to see it.

from ripgrep.