Is ripgrep Faster Than grep? I Benchmarked Both

Short answer: yes — but not by as much as the hype suggests. I benchmarked GNU grep 3.11 against ripgrep 14.1.0 on 832MB of real system files, running 5 different search tests with 7 timed runs each. Out of the box, ripgrep was 2.3x faster. But on plain text searches with equivalent settings, 50-year-old grep essentially tied it. The speed gap comes less from raw engine speed and more from ripgrep refusing to waste time on files you didn't mean to search. Here's the full breakdown.

How I Tested This

Fair benchmarks compare equivalent work, so I was careful about one trap: ripgrep skips binary files by default, while grep -r searches them. On my first run, grep "found" 806 more matching files than ripgrep — all fonts, tarballs, and other binaries where the search bytes happened to appear. That's not grep being thorough; that's noise.

So I ran 5 tests on the corpus /usr/share (832MB of real mixed files on Ubuntu 24.04, 2 CPUs):

1. Literal string, text only — grep -r -I -l "the" vs rg -l "the" (identical 8,535-file set)
2. Regex, text only — grep -rE -I -l "[a-z]+@[a-z]+\.[a-z]{2,}" vs rg -l with the same pattern (identical 1,902-file set)
3. Fixed string, text only — grep -rF -I -l "function" vs rg -F -l "function" (identical 1,729-file set)
4. Including binaries, equivalent work — grep -r -l "the" vs rg --text -l "the" (identical 9,341-file set)
5. Out-of-the-box defaults — grep -r -l "the" vs rg -l "the" (what people actually type)

I verified the file sets were byte-identical between the two tools for each paired test (sorted file lists, diffed). Each test got 3 warm-up runs followed by 7 timed runs; I report the mean. Page cache was warm throughout — cold-disk runs weren't possible in this sandbox (dropping caches is blocked), so treat these as "repeated search" numbers, the common case.

The Results

Full spread across the 7 runs was tight (min/max mostly within ~15% of the mean), so these aren't flukes.

The headline finding: on plain-text searching with equivalent settings, grep and ripgrep are basically tied. Tests 1 and 3 differ by 3–9% — within run-to-run noise on a 2-CPU machine. The "10x faster" claims you see online come from different conditions (much larger corpora, cold disks, or grep pointlessly chewing through binaries and node_modules).

Where ripgrep genuinely pulls ahead:

• Regex (test 2): 1.3x faster, thanks to its SIMD-optimized regex engine.
• Binaries (test 4): 2.1x faster. grep spends ~0.7s grinding through font files and tarballs; ripgrep detects and skips them.
• Defaults (test 5): 2.3x faster and cleaner output — 8,535 files vs grep's 9,341, with the 806 extras being binary junk.

The Real Advantage Isn't Speed — It's Defaults

The benchmark reframed the question for me. ripgrep's biggest win isn't its engine; it's that its defaults match what you actually want. I demonstrated this with a tiny project folder:

$ grep -r -l "hello" .
./.hidden.js
./app.js
./node_modules/dep.js

$ rg -l "hello" .
./app.js

Out of the box, ripgrep skips hidden files and everything in .gitignore (so node_modules/, .git/, build output all vanish from results). With grep, you hand-write --exclude-dir=node_modules --exclude-dir=.git every time — or you wait. ripgrep also parallelizes across CPU cores by default and prints colorized, line-numbered output without flags. None of this is magic; it's just better defaults, and according to the project's own documentation, the parallel directory traversal plus skipping ignored files is where most real-world speedups come from (ripgrep repo).

When grep Is Still Fine

Honest counterpoints, from the same test bench:

• Simple text searches on warm data: it's a tie. If your workflow is grep -r "string" src/, installing ripgrep won't make it meaningfully faster.
• It's already everywhere. grep ships with every Linux, macOS, and Unix system. ripgrep needs installing (sudo apt install ripgrep on Ubuntu). For scripts others will run, grep is the portable choice.
• Muscle memory counts. If you know grep's flags by heart, the 0.4s-vs-0.4s difference won't change your life.

Where I'd actually recommend switching: large codebases, monorepos with heavy node_modules, regex-heavy searching, and any "find in project" workflow you run dozens of times a day. That's also why coding agents and editors (VS Code's search is ripgrep under the hood) standardized on it.

FAQ

Is ripgrep a drop-in replacement for grep? Mostly, for interactive searching. It isn't identical: it skips hidden files, binaries, and .gitignored paths by default, and some exotic grep flags have no equivalent. For scripts, keep grep for portability.

How do I make grep behave like ripgrep's defaults? grep -r -I --exclude-dir=node_modules --exclude-dir=.git "pattern" . gets you most of the way there. The -I (skip binary) flag alone closed most of the gap in my tests.

Does ripgrep respect .gitignore? Yes — demonstrated above. Use -u/--unrestricted to disable the filtering (repeatable up to -uuu for "search literally everything").

Is grep faster on a single large file? I didn't test that here (my corpus was many small files). ripgrep's parallelism helps less on one file; one published benchmark on a 9.4GB log file reported a smaller ripgrep edge (~1.6x), according to that write-up. Your bottleneck there is disk speed either way.

Which should I install? If you search code daily: ripgrep. If you write portable shell scripts: grep. They coexist fine — I keep both.

Conclusion

ripgrep is faster than grep where it counts: 2.3x out of the box on my 832MB test, with cleaner results. But the legend of "10x faster" didn't survive contact with a fair test — on equivalent plain-text work, 50-year-old grep tied it. ripgrep wins by being smarter about what not to search (binaries, hidden files, gitignored junk) and by parallelizing the walk. That's a better reason to switch than raw speed: fewer flags to remember, less noise in results, and a meaningful speedup on real project trees. Install it if you live in a terminal; keep grep for your scripts.

How this article was made

Tested (2026-10-22, Ubuntu 24.04, 2 CPUs): GNU grep 3.11 vs ripgrep 14.1.0, corpus /usr/share (832MB). A Python harness ran 5 paired tests (literal/regex/fixed-string text-only with byte-identical file sets verified via sorted diffs, one binary-inclusive test, one out-of-box defaults test), each with 3 warm-up + 7 timed runs; means reported above. File-set equivalence: grep -r -I ≡ rg (8,535 files) and grep -r ≡ rg --text (9,341 files). The .gitignore/hidden-file demo was run in a scratch directory as shown. Page cache was warm for all runs (dropping caches is blocked in this sandbox). Raw results kept in the project workspace.

Researched: ripgrep's documented design (parallel traversal, default ignore rules) via the project's GitHub repository; GNU grep's manual for flag behavior. No third-party benchmark numbers are quoted as my own.

This article was drafted by Tiny, UnlockProof's AI assistant, which ran all the benchmarks above. It was reviewed by TAHSEEN, UnlockProof's human owner and editor, before publishing.