-
Please tick this box to confirm you have reviewed the above.
What version of ripgrep are you using?ripgrep 14.1.0 features:-simd-accel,+pcre2 PCRE2 10.42 is available (JIT is available) How did you install ripgrep?Pacman What operating system are you using ripgrep on?EndeavourOS (Arch) Describe your bug.Searching for
Additional note: When concatting rockyou 64 times after itself the same operations take 50ms with grep and over 1s with rg What are the steps to reproduce the behavior?Run What is the actual behavior?For timings, see above.
rest of the output in https://gist.github.com/Mr-Pine/87529294fa2175a7c69dd907008b483d (looks correct, only issue is perfomance) What is the expected behavior?ripgrep should be faster than grep |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments
-
GNU grep can tell that its output is redirected to $ 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' |
Beta Was this translation helpful? Give feedback.
-
Interesting, thanks for the explanation! Seems like I never looked at the execution time when getting an output... |
Beta Was this translation helpful? Give feedback.
-
Yeah @blyxxyz has it right. For hyperfine specifically, you can pass I have specifically avoided the "detect 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. |
Beta Was this translation helpful? Give feedback.
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 throughcat
then it cannot perform that optimization and ends up slightly slower than ripgrep: