Comparisons · measured July 2026 · 8 min read
ripgrep vs the Silver Searcher (ag): the fast-grep showdown.
If you search code for a living, you have a favorite here. The Silver Searcher lit the fuse in 2011: it taught grep to respect your project and use every core. ripgrep arrived in 2016, kept the ergonomics, rebuilt the engine in Rust, and quietly took the crown. This is the honest scorecard: what each improved, which one is quicker, and the twist neither camp likes to hear: the whole race was run on the wrong track.
Because the gap between them is single-digit, a few times faster, benchmark to benchmark. The gap that decides whether your AI agent waits is 58,625×. They spent a decade sprinting against each other inside the same cage: on a big enough drive, both still walk the disk on every single query.
The two contenders
Two answers to one question. Both brilliant. Both walking.
The Silver Searcher (ag) is a fast, code-aware content search tool (written in C, released in 2011 by Geoff Greer, and named for silver's chemical symbol) that searches inside your files while automatically skipping whatever your .gitignore and version control already hide. It was the tool that made searching a codebase feel designed rather than endured.
ripgrep (rg) is a fast, multithreaded content search tool (written in Rust, released in 2016 by Andrew Gallant) that keeps that same code-awareness and adds a finite-automata regex engine, so it searches whole trees quickly without a pattern ever blowing up into catastrophic backtracking. Both descend from one idea: teach grep to honor your project and spread the work across every core.
The lineage. The Silver Searcher (ag) came first, in 2011, and made code search ergonomic: skipping .gitignore’d files, fanning the search across cores, grouping and coloring matches. ripgrep (2016) kept all of it and rebuilt the engine in Rust.
Who wins the sprint. On large trees, published benchmarks (including ripgrep author Andrew Gallant’s own, which pits rg against ag directly) generally put ripgrep ahead, by single-digit multiples. Both are far faster than plain grep -r.
The shared ceiling. Both still open, read, and close every file on every query. Their cost grows with the size of the disk, not the size of your question: double the files and you double the walk, forever.
The gap that matters. ag-versus-ripgrep is a few times. Walk-versus-index is 58,625×: 93.8 seconds of walking against 16 milliseconds of look-up, same query, same 4.47M-file machine.
Keep both. For one file or a pipe in the folder you are standing in, a walker is perfect. For the whole machine, an index answers first, and Interlinked puts a live one over every drive.
The honest read: this is a rivalry of refinements. ag proved the shape; ripgrep polished it. If you only ever remember one line from the showdown, make it the last one: the winner between these two is a rounding error next to the tool that stops walking.
The showdown, drawn
Every win sped up the walk. None of them skipped it.
Read it top to bottom. The ledger up top is the feature-by-feature scorecard: where ag and ripgrep match (the code-search ergonomics ag drew first) and where they split (ripgrep's Rust engine). The axis below is what all of that buys on one content query across 4.47 million files: a faster walk that still lands inside the same ceiling. A prebuilt index is the only marker that escapes it.
ripgrep's 93.8 s is measured. ag and grep were not timed on this volume; both do the same open-read-close walk, so they sit in the ceiling band: those positions are illustrative, not measured. Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4.47M files.
The showdown, scored
A photo finish between them. A blowout against the walk.
The ag-versus-ripgrep result is close and genuinely contested: reasonable engineers run either one and are happy. ripgrep tends to edge it on big trees; ag is the tool that made the category exist. Both are worth keeping. But zoom out one level and the contest turns to trivia: point either walker at a whole machine and the reading is the cost. Measured on one real drive:
| The tool | Engine & method | Result | vs the index |
|---|---|---|---|
| The fast-grep sprint · which walker is quicker | |||
| ripgrep (rg) | Rust automata regex · SIMD literals · parallel walk | fastest walker | still walks |
| Silver Searcher (ag) | C · PCRE regex · mmap · parallel walk | the pioneer | still walks |
| The real race · walk vs index · one content query · 4.47M files | |||
| Interlinked | reads a live index, opens no files | 16 ms | 1× baseline |
| ripgrep or ag | open · read · close, every file, every query | 93.8 s | 58,625× slower |
Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. ripgrep with default settings (.gitignore respected). The 93.8 s figure is one query in a five-query content set; across the set the look-up averaged ~8 ms, 58,625× faster. ag was not timed on this volume: it does the same open-read-close walk, so it lands in the same band; the ripgrep-versus-ag ordering follows public benchmarks, including ripgrep author Andrew Gallant's. Full per-tool method in the ripgrep content comparison and the ripgrep-vs-grep write-up.
The twist
They optimized the walk. Nobody removed it.
The whole ag-to-ripgrep story is a five-year effort to make one operation faster: the walk. A better ignore-matcher so fewer files get opened. A parallel traversal so cores share the load. A regex engine that scans literals with SIMD and can't catastrophically backtrack. Every one of those wins is real, and ripgrep earned its reputation on them. But a faster walk is still a walk. To answer “which files contain this,” a walker has to visit the files (open, read, scan, close) and the bill scales with the size of the disk, not the size of your question. Double the files and you double the work, for both of them, every query, forever.
A purpose-built engine does the walk exactly once, in the background, when nobody is waiting, then keeps a live index that updates as files change, so a saved edit is searchable again in about a millisecond. At query time there is no tree to crawl and no file to open. The ag-versus-ripgrep multiple is single-digit; the walk-versus-index multiple is five orders of magnitude. The winner of the showdown is a rounding error next to the tool that stops walking.
The tool that leaves the cage
Both contenders open every file. The winner opens none.
An index sounds heavy until you measure it. It reads the disk once, then stays fresh without a re-scan, sits quietly in the background, and costs a rounding error of your drive, while turning every content query from a minutes-long walk into a look-up you don't notice. This is the whole idea behind Interlinked, laid over your entire machine: every repo, plus the ninety percent of the drive that was never in a repo.
And there is no model in the loop: no embeddings, no guessing, no cloud round-trip. A look-up is a look-up: a word, a row, a list of files. It is the same fast floor every AI agent stands on, which is the larger story in the backbone of the LLM economy.
What this costs your agent
Your agent already picked a side. It picked a walker.
When a coding agent (Claude Code, Cursor, Copilot, Windsurf, Cline, Aider) needs content it can't recall, it shells out to ripgrep or ag machine-wide, on every question it can't answer from memory, and hits the ceiling dozens of times per turn. Which fast-grep it chose barely matters. That it walks at all is the whole bill.
The filename median across 20 queries was 139 µs; the best single lookup, 2 µs. Drop the query cost five to seven orders of magnitude and the agent stops rationing questions: it verifies every callsite, checks every import, asks the speculative ones it used to skip. The same live index also carries short notes agents leave on files, so the next agent reads what the last one learned. Same tools. A floor that answers first.
Questions people ask
ag vs ripgrep, answered.
Is ripgrep faster than the Silver Searcher (ag)?
Generally yes, on large directory trees: ripgrep's author, Andrew Gallant, published a rigorous benchmark that pits ripgrep against ag and other tools and it usually comes out ahead, thanks to a finite-automata regex engine and SIMD-accelerated literal scanning. But the margin is single-digit; both crush plain grep -r. The gap that actually changes your day is walk versus index: 93.8 s against 16 ms on the same query.
What does “ag” stand for?
ag is the command name for the Silver Searcher: Ag is the chemical symbol for silver. Geoff Greer released it in 2011, and it pioneered the code-aware search (automatically skipping files your .gitignore already hides) that ripgrep later refined.
Should I switch from ag to ripgrep?
If you search big trees often, ripgrep is a reasonable default: quicker in most benchmarks, actively maintained, and its regex can't blow up into catastrophic backtracking. But either is excellent for a single tree, and switching between them only moves you a few percent. The switch that actually changes your day is adding an index for whole-machine search.
Do ripgrep and ag search the whole machine?
They can: point either at your root and it will search everything. The catch is that they walk every file on every query, so a machine-wide content search costs seconds to minutes and grows as your drive fills. See why every walker shares that ceiling. A prebuilt index answers the same question in milliseconds because the reading already happened.
Does Interlinked replace ripgrep or ag?
No. Keep both for one file, a live pipe, or a quick regex in the folder you are already in. That is exactly what they are built for. Interlinked answers first on the whole-machine questions a walk would spend minutes on, 16 ms against 93.8 s, and its index stays live so a saved edit is searchable again in about a millisecond.
Give your fast-grep a faster floor
Keep ag. Keep ripgrep.
Install once. One signed installer wires up 19 AI clients: Claude Code, Cursor, Copilot, Codex, Windsurf, Zed and the rest. No JSON to edit.
Keep your walker. ag and ripgrep stay exactly where they are, still perfect for one file, a pipe, or a quick regex in the folder you are in. The index just answers first: machine-wide, in the microsecond-to-millisecond range.
Let it stay fresh. Save a file and it is searchable again in about a millisecond. At rest the whole engine sits around 44 MB and the index takes under 1% of the drive.
Everything local is free, forever: the app, whole-machine search, MCP. Hosting starts at $5.99/mo. Download for Windows.