While sometimes a plausible explanation for huge differences in search time, there are at least two other possible explanations.
First is parallelism. If you do `grep -r`, most greps (like GNU grep and BSD grep and the one found on macOS) will not use parallelism. ripgrep will. This could easily account for a large perceived difference in search time.
Second is the grep implementation. While GNU grep is generally considered to be quite fast on its own (especially in the POSIX locale), many other grep implementations are not. And indeed, they may be extraordinarily slow. For example, consider this comparison between FreeBSD grep (on macOS) and ripgrep (I clipped the `time` output for the `wc -l` command, which I just used to make the output smaller):
$ time rg -j1 -uuu -w -g '*.c' '[A-Z]{2}_RESUME' | wc -l
22
real 0.769
user 0.105
sys 0.662
maxmem 5104 MB
faults 0
$ time LC_ALL=C grep -E -w -r --include '*.c' '[A-Z]{2}_RESUME' | wc -l
22
real 15.830
user 14.576
sys 1.253
maxmem 2224 MB
faults 1
$ time LC_ALL=C ggrep -E -w -r --include '*.c' '[A-Z]{2}_RESUME' | wc -l
22
real 1.148
user 0.206
sys 0.767
maxmem 2784 MB
faults 1
This is just a straight up comparison that removes things like parallelism and filtering completely. This is purely algorithms. And the difference is an order of magnitude.Any one of these explanations, on its own, can account for huge differences in perceived performance. It's not really possible to know which one (perhaps even all 3) is relevant from pithy descriptions of ripgrep being so much faster than other tools.
Version info for above commands:
$ rg --version
ripgrep 14.1.1 (rev bb88a1ac45)
features:+pcre2
simd(compile):+NEON
simd(runtime):+NEON
PCRE2 10.45 is available (JIT is available)
$ grep -V
grep (BSD grep, GNU compatible) 2.6.0-FreeBSD
$ ggrep -V
ggrep (GNU grep) 3.12
Packaged by Homebrew
Copyright (C) 2025 Free Software Foundation, Inc.
[.. snip ..]