History · April 2026 · 6 min
From fifteen seconds
to eighty-five microseconds.
Thirty years of file search on Windows. The tools tracked the disk and never actually got faster. This year, one finally broke the pattern.
TL;DR · Key takeaways
Everything below, in five points.
Filename search: resolves one name in 85 µs best case (139 µs median across 4.47M files): 412,000× faster than VS Code, ~480,000× faster than Windows Search's 67 s.
Content search: answered from a prebuilt index in 7 to 9 ms. A query that took ripgrep 93.8 s cold drops to 16 ms, about 58,625× faster, because nothing re-reads the disk between runs.
For AI agents: a code search that cost an agent 6m57s across 71 tool calls collapses to a single 16 ms call: roughly 7,200,000× less wall time, with search's token cost falling from ~58% of the context window to ~0%.
Footprint: about 44 MB at idle, and the index refreshes in ~1 ms after any file changes. Benchmarked on a Ryzen 9 9950X3D across 4.47M files.
Pricing: everything is free forever, no card. Hosting starts at $5.99/mo.
Interlinked Files (2026)
best case · 4.47M files · L2 cache hot path
VS Code · Go to File (2026)
same 4.47M-file drive · re-scans the tree · well above human perception
Speed multiplier
faster than VS Code's file search on the same 4.47 million-file drive. Eighty-five microseconds against thirty-five seconds. Same hardware.
The full timeline
Six rows, six orders of magnitude.
| Year | Engine | Wall clock | Note |
|---|---|---|---|
| 1995 | Windows 95 Find | ~15,000 ms | Recursive directory walk. No index. Hope you brought a book. |
| 2000 | Windows 2000 Indexing Service (CiDaemon) | ~8,000 ms | First real indexer. Slow, heavy, off by default. |
| 2005 | Windows Desktop Search 2.x | ~5,000 ms | Faster, but optional. Nobody installed it. |
| 2026 | VS Code, Go to File | ~35 s | The tool developers live in. Re-scans the folder tree on a 4.47M-file drive. |
| 2026 | Windows Search (indexed) | ~67 s | The OS's own indexer, on the same 4.47M-file machine. Still tens of seconds. |
| 2026 | Interlinked Files | 139 µs | Prebuilt index, answered from L2 cache. 85 µs best case; median across 4.47M files. |
All benchmarks on the same 4.47M-file C: drive where possible. Early-era numbers are representative, not exact: nobody benchmarked the Windows 95 Find dialog carefully.
Jump one · 1995 to 2005
The walker era. No index. No hope.
For a decade, Windows file search was a recursive directory walk with no persistent data structure. Every query started from the root, visited every file and folder, compared names, returned hits. On the drives of the era (a few gigabytes, a few hundred thousand files) it took five seconds to a minute.
The animated magnifying glass in XP's Search Companion became the universal symbol of waiting. CiDaemon existed but was off by default. Windows Desktop Search 2.x shipped as a free download. Neither had competitive pressure to improve because the alternative was no indexer at all.
Best case (2005)
Five full seconds. For one query.
Typical case
Fifteen seconds. Users learned not to search.
The wall · 2026
Faster hardware, same wait.
Thirty years of Moore's law went into the disk, not the search. A modern NVMe drive reads gigabytes per second, yet the tools people actually use still make you wait. On a 4.47-million-file drive, VS Code's Go to File takes about thirty-five seconds to settle. Windows Search (the indexed one, built into the OS) takes sixty-seven.
Content search is worse. ripgrep is the fastest cold grep ever written and it still spends ninety-four seconds re-reading every byte on disk, because it keeps no index between runs. The common thread: every query scales with the file count. More files, more wait. For thirty years, nothing broke that link.
Windows Search
The OS's own indexer, on 4.47M files
ripgrep · content
Fastest cold grep there is. No index between runs.
Thirty years of file search, and the wall clock never left the seconds.
Every tool scaled with the disk. Hardware got faster; the wait didn't.Jump two · 2026
Another three orders of magnitude.
Getting from thirty-five seconds to eighty-five microseconds isn't a matter of writing faster C. It's a matter of designing the index so the hot path fits in L2 cache, the query traversal has zero branch mispredictions, and the daemon's IPC layer doesn't dominate the wall clock.
The hardware of 2026 (DDR5, AVX-512, sixteen-core consumer CPUs, L3 caches the size of a 2006 CPU's total RAM) makes this possible. It simply wasn't buildable a decade ago; the parts weren't there.
The architectural shift
VS CODE (2026)
Cold folder walk → re-index on open → scan
No index kept between sessions. Every query scales with the file count.
INTERLINKED (2026)
Flat arena + trigram index → cache-line aligned → SIMD scan
Hot path fits L2. Zero allocations per query. No branch mispredictions.
Same NTFS drive. Same 4.47 million files. Different data structure.
Two jumps
One small, one enormous.
Walking the tree to indexing it bought about 3×, and then decades of hardware bought almost nothing. Interlinked's jump is nearly half a million times, from rebuilding the data structure for the modern memory hierarchy.
For AI agents
Context retrieval is no longer a bottleneck. The model doesn't wait for the file system.
For humans
Type a filename. Results appear before your finger leaves the key. No spinner. No delay.
For services
Runs as a Windows Service. Auto-start. Auto-restart. Invisible. Zero CPU at idle.
Looking ahead
Is 85 µs the floor?
Probably not, but the next jump won't come from software. At these speeds, the IPC layer and the operating system become the wall. A faster index wouldn't help, because the query clock is already dominated by kernel context switches and the latency of waking a handler thread.
To go substantially lower, you'd need new OS primitives: something like io_uring for indexed lookups, or a way to register callbacks that run without a context switch.
The next big jump, whenever it comes, will come from hardware: persistent memory that blurs the line between DRAM and storage, or CPU features that make cross-process IPC cost zero. When that shows up, somebody (us, or somebody else) will take another three orders of magnitude off the wall clock, and this table gets another row.
For now, tens of microseconds is the floor. The only thing standing between you and instant file search is whether you've installed the tool.
Common questions
The questions people ask first.
How is it 412,000× faster than VS Code?
It keeps a prebuilt index resident in memory instead of walking the folder tree on every query. The hot path fits in L2 cache, so a filename resolves in 85 µs best case (139 µs median across 4.47 million files) rather than the seconds every walker-based tool spends re-scanning the disk.
Does it search inside file contents, or only filenames?
Both. Content search answers from a prebuilt index in 7 to 9 ms. In one benchmark a query that took ripgrep 93.8 s cold fell to 16 ms (roughly 58,625× faster) because the index is never rebuilt from scratch between runs. Document text (PDF, Word, Excel) is indexed too.
Why does this matter for AI agents like Claude Code?
Search stops being a bottleneck. A code-search task that took an agent 6m57s across 71 tool calls collapses to a single 16 ms call (about 7,200,000× less wall time) and cuts that search's token cost from roughly 58% of the context window to about 0%.
How much memory does it use, and does the index stay fresh?
About 44 MB at idle. When a file changes, the index updates in ~1 ms, so results are always current. It runs as a Windows service: auto-start, auto-restart, and effectively zero CPU when idle.
How much does it cost?
Everything (including the MCP server your AI clients connect to) is free forever, no card. Hosting starts at $5.99/mo.
Thirty-five seconds → eighty-five microseconds.
Same machine. Same 4.47 million files. 412,000× apart.