Methodology · Apr 9 2026 · 5 min
4.47 million
files.
Every number on this site comes from the same corpus. A developer's C: drive after three years of use (4 TB4 Terabytes, 4.47 million files). No synthetic filesystems. No freshly expanded tarballs. Tuesday afternoon.
Total files
NTFS, single C: volume
Content-indexed
Code files read end-to-end
Directories
Up to 18 levels deep
Drive size
Real working drive, not synthetic
TL;DR · Key takeaways
The short version if you only read one block.
Every benchmark on this site runs against one real corpus: a developer's 4.47-million-file C: drive (4 TB, 446K code files content-indexed) on a Ryzen 9 9950X3D. No synthetic filesystems.
Filename search returns in 85 microseconds for a single file (139-microsecond median) across all 4.47M files, about 412,000x faster than VS Code and ~480,000x faster than Windows Search (67 s for the same query).
Content search answers in 7 to 9 milliseconds across 446K code files. A grep that takes ripgrep 93.8 s cold returns in 16 ms on the warm index, a 58,625x speedup.
For an AI agent, a whole-machine lookup costing 6m57s across 71 tool calls collapses to 16 ms in one call (~7,200,000x), cutting search's token burn from ~58% to ~0%.
It stays out of the way: ~44 MB idle, ~1 ms freshness. Everything is free forever, no card. Hosting starts at $5.99/mo.
Filename index
Every file on the drive
Content index
Code files only · ~18 GB of source
The corpus
Six things about the drive every number came from.
| Dimension | Count | Notes |
|---|---|---|
| Total files on the volume | 4,470,000 | NTFS, C: drive |
| Code files (content-indexed) | 446,000 | TypeScript, Rust, Go, Python, C++, etc. |
| Total directories | ~387,000 | Folder tree depth up to 18 levels |
| Largest single file | ~4.2 GB | Disk image; skipped for content index |
| Files touched in last 30 days | ~180,000 | Live-indexing burden |
| Hidden / system files | ~812,000 | Excluded by default, reachable with a flag |
No synthetic filesystems. No curated subsets. This is the drive as it exists on the test machine, the day the numbers were taken.
Why size matters
Most benchmarks lie by picking a small corpus.
A file search engine's speed is a function of how many files it has to consider. Drop the corpus size by 100x and every engine looks fast.
You can make almost any search engine look good on a thousand-file test. Walk the directory, scan every byte, return the answer in milliseconds. Nobody notices the walk because the walk was cheap. The test didn't stress what the engine is supposed to do.
At a million files the walk stops being free. At four million files the walk is the entire cost. Below the million-file mark, the difference between a naive tree walker and a purpose-built index is barely visible. Above it, the difference is six orders of magnitude.
4.47 million is not a stress test. It's a developer machine that has had a few years of node_modules, target/, .venv/, Unity caches, Steam installs, and Visual Studio components. We're testing against Tuesday afternoon.
At 1K files
Every engine is fast
At 1M files
Walkers start choking
At 4.47M files
Index wins by 6 orders
412,000x. That's the gap between walking and indexing at 4.47M files.
We picked this corpus because it's where the difference stops being theoretical.Two indexes, one drive
Filenames vs contents are different jobs.
Filename search answers “where is the file named X?” (it needs to know every path but nothing about what's inside). Content search answers “which files mention Y?” (it has to read the bytes).
Indexing filenames is fast and cheap. Indexing contents is slower and only worth doing for files you'll actually search by content. Source code, docs, config files, markdown: yes. Photos, videos, compiled binaries, database pages: no.
Whenever you see a filename-search benchmark on this site, the corpus is 4.47M files. Whenever you see a content-search benchmark, the corpus is 446K files. Two indexes, same drive, different jobs.
The hardware
A fast desktop, not a datacenter.
| Component | Spec | Notes |
|---|---|---|
| CPU | AMD Ryzen 9 9950X3D | 16 cores, 32 threads, 3D V-Cache |
| RAM | 64 GB DDR5-6000 | Dual channel |
| Storage | 2 TB NVMe Gen 4 | Single drive, C: volume |
| OS | Windows 11 Home | Build 10.0.26200 |
| Thermals | Idle thermal floor | No throttling observed |
The 9950X3D is fast. We're not going to pretend it isn't. If you run the same benchmarks on a laptop you will see slower numbers, but the ratio between engines stays the same. The 412,000x gap isn't a function of our CPU. It's a function of VS Code walking a directory tree and an indexed engine consulting a prebuilt table.
What accumulates
4.47 million is not unusual.
A single node_modules install can create 50,000 files. A Rust project's target/ folder grows to hundreds of thousands. Unity cache, Steam, Visual Studio, Electron dev builds: they all compound.
After three years of development work, a developer's C: drive crosses four million files without trying. We benchmarked against the real thing.
Active files (30 days)
Live-indexing burden
Hidden / system
Excluded by default
Content indexed
Of source code read end-to-end
The principle
Same drive. Every time.
Every benchmark on this site (filename search latency, content search throughput, index build time, memory usage) runs against this exact corpus on this exact hardware. No cherry-picking favorable subsets. No switching machines between tests.
When we say 14 microseconds for filename search, that's across 4.47 million files. When we say 8 milliseconds for content search, that's across 446,000 code files totaling 18 GB. One corpus. One machine. Every number.
Common questions
The questions this benchmark tends to raise.
Why benchmark against 4.47 million files instead of a small test set?
Because the size is the point. Below a million files almost any engine looks fast: the directory walk is cheap, so nobody notices it. At 4.47 million files the walk becomes the entire cost, and that's where a prebuilt index pulls ahead by six orders of magnitude, about 412,000x versus VS Code. The corpus is a real developer's C: drive after a few years of use, not a synthetic filesystem.
How fast is a single filename search across all 4.47 million files?
About 85 microseconds for a single file, with a 139-microsecond median. That is roughly 412,000x faster than VS Code's search and around 480,000x faster than Windows Search, which takes about 67 seconds for the same query.
What about searching inside file contents?
Content search runs against the 446K content-indexed code files and returns in 7 to 9 milliseconds. A query that takes ripgrep 93.8 seconds on a cold cache resolves in about 16 milliseconds on the warm index (a 58,625x speedup) because the bytes were read once, ahead of time.
Does this actually matter for an AI agent?
It is the difference between usable and not. A whole-machine lookup that costs an agent 6m57s across 71 tool calls collapses to a single 16-millisecond call, around 7,200,000x faster, and cuts the share of tokens spent searching from about 58% to nearly 0%. The index sits at roughly 44 MB idle with about 1 ms freshness, so a file edit is searchable almost immediately.
Do I need this exact hardware, and what does it cost?
The absolute latencies come from a Ryzen 9 9950X3D, so a laptop will post slower numbers, but the ratio between engines holds, because it measures walking versus indexing, not our CPU. Everything local is free, forever: the app, whole-machine search, MCP. Hosting starts at $5.99/mo.