Explainers · measured July 2026
What is ripgrep, and why is it so fast?
ripgrep is the search tool your editor and your AI agent almost certainly use under the hood. It is a ground-up rewrite of grep in Rust: multithreaded, SIMD-accelerated, and a genuinely great piece of engineering. This is a friendly explainer of what it does, why it left grep behind, and the one wall every filesystem walk eventually hits: on a 4.47-million-file machine, the same search that takes ripgrep 93.8 seconds takes a warm index 16 milliseconds.
grep, 1973 → ripgrep, 2016
Same job as grep. Every part of it, faster.
grep, born in 1973, does one honest thing: read a stream of text line by line and print the lines that match a pattern. One file at a time, one core, one line at a time. For a single file or a Unix pipe it is still perfect. Point it at a large tree of source code and the design starts to show its age.
ripgrep keeps the job and rebuilds the machine underneath it. Four decisions do most of the work:
than grep on large trees, in ripgrep's own published benchmarks. That is why VS Code's find-in-files shells out to ripgrep, and why so many AI coding agents reach for rg by reflex.
The one picture worth keeping
The walk touches every file. The index jumps straight to the answer.
Both lanes run the exact same query on the exact same machine. The grid is a stand-in for the whole drive. Watch what each tool has to touch to answer.
Why the fastest walker still hits a wall
A walk is work you pay every time you ask.
same content query · same 4.47M-file drive · ripgrep, then a warm index
None of this is a knock on ripgrep. ripgrep is the best possible way to walk a filesystem. But every walk is O(files): to know which files contain a string, you must open, read, and close each one. No amount of per-byte cleverness escapes that. On a repo of a few thousand files, that is milliseconds, instant. On a whole 4.47-million-file drive, the floor is measured in minutes.
The 93.8 seconds isn't ripgrep being slow. It is ripgrep re-walking 4.47 million files because you asked again. Across a five-query content set, the index came back 58,625× faster than ripgrep, an average of about 9 milliseconds a query. The walk was already done.
This is also why VS Code feels quick and yet can't answer machine-wide questions: it scopes ripgrep to the folder you opened. Fast for one project, blind to the other repos and the git-ignored files a repo-scoped walk never sees. grep, without ripgrep's parallelism and SIMD, sits further down the same wall.
Same query · same drive · same machine
Four tools, one 4.47-million-file question.
| The tool | How it searches | Built for | Same query · 4.47M files |
|---|---|---|---|
| Interlinked | Prebuilt content index, no walk | the whole machine | 16 ms |
| ripgrep (rg) | Parallel walk · SIMD · mmap | a repo | 93.8 s |
| VS Code find-in-files | ripgrep under the hood, folder-scoped | the open workspace | the same walk, scoped |
| grep -r | Single-threaded line scan | one file / one pipe | the walk, without the speed tricks |
The two rows with hard numbers are the same content query, timed twice: ripgrep re-walking the drive at 93.8 seconds, the index answering it at 16 milliseconds. Across the full five-query set the index averaged about 9 ms: content search lands in the 1 to 10 ms range whatever the drive holds.
Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. ripgrep run with default settings (.gitignore respected). VS Code and grep rows describe their search method; they are variants of the same filesystem walk, not separately timed here.
The layer above the walk
Don't walk faster. Walk once, then never again.
Interlinked doesn't compete with ripgrep: it sits above it. It walks the machine one time, in the background, and keeps that map fresh as files change: a save is searchable in about a millisecond, under 30 ms in the worst case. After that, every query is a lookup, not a walk, so it holds the same 1 to 10 ms whether you point it at one repo or the whole drive, across every repository and the git-ignored files a repo-scoped tool never reaches. Keep ripgrep for the folder you have open; let the index answer everything else.
The cost of keeping that map warm: about 44 MB of memory at rest (less than a browser tab) and an index that stays under 1% of the drive (roughly 24 GB on a 4 TB machine). When a query is five orders of magnitude cheaper, an agent stops rationing questions and starts checking every callsite.
Put the index under your agent
Keep ripgrep. Add the layer above it.
Install once. One signed installer auto-configures 19 AI clients: Claude Code, Cursor, Copilot, Codex, Windsurf, Zed, Cline and the rest. No JSON editing.
Let it walk once. It maps the machine in the background and keeps it fresh as you edit. Filename search works immediately; content search fills in behind it.
Ask machine-wide. Whole-machine when you don't know where something lives, scoped to a folder when you do. Content answers land in the 1 to 10 ms range either way.
Everything local is free forever, on all your devices, no card. Hosting starts at $5.99/mo. Download for Windows.