Interlinked.

History · Apr 9 2026 · 8 min

Thirty years
of good intentions.

The thing built into the Start menu of every Windows machine in the world, designed by the people who wrote the operating system, takes sixty-seven seconds to find a file that an indexed engine finds in eight milliseconds. This is not a bug. It is three decades of architecture.

1995No index. Full walk.
2005First indexer. Slow.
2007Vista. RAM hog.
2015Cortana. Web merged.
2021Win 11. Still not instant.
202667.1 seconds.

Indexed search

8ms

Interlinked Files · 4.47M file corpus

Windows Search

67.1s

Same machine · same drive · same query

Thirty years of Windows file search

From a walker to an indexed walker.

The history of Windows file search is the history of Microsoft noticing the previous version was slow, rebuilding it, and ending up with something only marginally faster.

YearMilestoneWhat changedResult
1995Start > Find > Files or FoldersNo index. Full directory walk every query.Minutes
2005Windows Desktop Search (XP add-on)First indexer attempt. Ran as a service. Slow to populate.Faster for indexed paths
2007Windows Vista: Instant SearchBuilt-in indexer. Consumes RAM. Users complain.10 to 30s for unindexed
2010Windows 7: scope narrowedMicrosoft restricts default index to user folders only.Less coverage
2015Windows 10: Cortana eraLocal search merged with Bing web results.Added latency
2021Windows 11: Enhanced modeOptional full-drive indexing. Still throttled.Not instant on 4M files
2026Windows Search todayPartial index + web merge + throttled service.67.1 seconds

Three compounding decisions

None of them wrong. All of them fatal.

Windows Search is slow because three architectural decisions, each rational in isolation, compound into the most polished bad file search in computing.

01

Partial index

Not indexing everything by default

Windows Search indexes a small subset of paths by default: your user folders, the Start menu, and not much else. Rational in 2007 when drives were slow and RAM was scarce. Twenty years later, any query for a file outside your profile either returns nothing or falls back to a slow walk. On a 4.47 million-file drive where most files live outside the default scope, this is the same as not having an index at all.

02

Web merge

Mixing local search with Bing

Since Windows 10, the Start menu search box is also the web search box. Every query contacts a remote service, waits for (or times out) web results, merges them with local results, and ranks them together. The user waits for the slower of the two before seeing anything. Even if the local index were fast, the web-merging layer on top keeps end-to-end time floating around several seconds.

03

Throttled service

Playing nice with everything

The indexer tiptoes: it yields to foreground programs, throttles its own IO, sleeps on battery. On a slow drive with an active user, the indexer never reaches steady state. Files you created this morning may not be indexed. Files deleted last week may still appear. Users notice, stop trusting it, and fall back to File Explorer search, which is a recursive walk. Even slower.

A partial index + a web merge + a throttled service = the most polished bad file search in computing.

The structural asymmetry

Every constraint Microsoft has, a third party doesn't.

Microsoft ships to a billion users who want everything for free, and a noticeable fraction of them don't want an indexer at all. They cannot index every file by default. They cannot consume 400 MB of RAM during a build. They cannot pin a core for ten minutes on first launch.

We can. Users who install Interlinked Files expect it. They opt into the aggressive side of the trade. File search goes from a minute to a microsecond. Everything else stays the same.

Microsoft

Partial index
Web merge
Throttled IO

Serves 1B users who didn't ask for this

Interlinked Files

Full index
Local only
Unrestricted IO

Serves users who chose speed

The cost of legacy

Where the time goes on every query.

StageWindows SearchInterlinked FilesWhy
Index scopeUser folders onlyEvery fileDefault coverage determines hit rate
Fallback on missFull directory walkNo fallback neededIndexed engines don’t walk
Web merge overhead~2 to 4s per query0sLocal-only means no network wait
Index freshnessHours behindReal-time (USN journal)Throttled vs. unrestricted IO
End-to-end query time67.1 seconds8 ms8,387× faster

The bottom row is the only row most users ever see. But the bottom row is the product of every row above it. Each architectural constraint adds latency. They compound multiplicatively, not additively.

Where the 67 seconds go

Anatomy of one Windows Search query.

You type a filename into the Start menu. Behind the scenes, Windows Search checks its partial index, finds nothing, falls back to a directory walk, simultaneously fires off a Bing request, waits for both, merges the results, and finally shows you the file. Here is where the time actually goes.

67.1 seconds total query budget
Index lookup ~2s: partial, misses most files
Directory walk ~55s
Bing web merge ~4s
Rank + merge + render ~6s

If you remove the directory walk

Windows Search

67.1s

82% is the walk. 18% is overhead.

Indexed engine

0.008s

No walk. Direct lookup. Done.

The directory walk is 82% of the total time. Eliminate it and the query moves six orders of magnitude.

The numbers

What happens when you remove every constraint.

Filename search

14µs

Best query on 4.47M files

Content search

4.8ms

446K code files, sparse ngram

Memory at idle

44 MB

vs 800 MB (Outlook) / unknown (WS)

Index build

48s

4.47M filenames, cold start

Live updates

USN

Real-time via NTFS change journal

Coverage

100%

Every file on every NTFS volume

8,387×

The speed difference between Windows Search and Interlinked Files on the same machine, the same drive, the same query. Not a synthetic benchmark. A real 4.47 million-file developer workstation. Every constraint removed. Every path indexed.

The lesson

Windows Search isn't broken. It's trapped.

Windows Search cannot index aggressively because it ships to a billion people who didn't ask for it. It cannot skip web results because that would break the Start menu UX model. It cannot consume real CPU because someone on a Surface Go would notice.

Third-party file search has always been faster than Windows Search and always will be. Not because the engineering is smarter. Because the permission model is different. Install Interlinked Files and you opt into the aggressive side of the trade. The constraints that cripple Windows Search do not exist here.

File search goes from a minute to a microsecond. Everything else stays the same.

Timeline compiled from Microsoft documentation, Windows SDK changelogs, and release notes. Benchmark numbers from a 4.47M-file corpus on a Ryzen 9 9950X3D with 64 GB DDR5. April 2026.