I Found a Windows Search Alternative That Costs /bin/sh and Works Instantly

Windows Search has been the slowest part of my workstation for as long as I have run Windows on the desktop. I will type a filename into the box, watch the blue bar crawl, and see my CPU spike to 80% for ten seconds before the file appears. The fans spin up. PowerShell scripts that should take a second take a minute. The search index rebuilds itself at random and eats the disk for an afternoon. It is the kind of background tax you stop noticing until you stop using it. I replaced it with a single command on a Linux machine and a tiny binary I copied to a Windows VM. Both run instantly, both are free, and neither one of them is “Everything” or “PowerToys Run”, which are the two answers you usually get.

What is actually wrong with Windows Search

The Windows Search service (a long-running background process called SearchHost.exe) maintains a search index, a database of every file on the system that the Start Menu and File Explorer query in real time. The index is supposed to make searches fast. The problem is the cost of keeping it current.

Every time you save a file, copy a directory, or extract an archive, the indexer wakes up and processes the new files. On a workstation with a spinning disk, that is fine. On a workstation with an SSD and a few hundred thousand files, the indexer competes with everything else for I/O. On a workstation with an antivirus product, the indexer also has to wait for the AV scanner to release each file before it can read it. The result is a system that stutters under load and a search box that takes longer to return a result than dir would have taken to scan the folder.

There is also a feature called “Content Search” that scans inside files. The indexer reads the contents of every .docx, .pdf, .txt, .eml, and .xlsx file on your disk and stores a hash of the content so that you can search across files, not just filenames. Content Search is the reason a full index rebuild takes six hours on a new install. It is also the reason half your disk is being read continuously. If you turn Content Search off in the Indexing Options control panel, search gets faster and the indexer chills out, but you lose the ability to find a phrase inside a Word document.

There is a third problem: Cortana integration. Until Windows 11, search was tied to Cortana (Microsoft’s voice assistant, discontinued in 2023 but its hooks remain in the code). Even with Cortana disabled, the search indexer still calls home for web results, which is why some searches return Bing results mixed with local files. Microsoft has been de-coupling this over the years, but the legacy code paths still cost CPU cycles.

The /bin/sh answer

I run Windows in a VM on a Linux host, and I keep a Linux terminal open in another window. When I want to find a file, I have gotten into the habit of typing the same shell pipeline over and over. Here it is:

find / -name "*.log" -type f 2>/dev/null | head -50

find is a Unix command that walks a directory tree and reports every file matching a pattern. The -name flag filters by filename, -type f keeps only regular files (not directories or symlinks), and 2>/dev/null suppresses the permission-denied errors that litter a multi-user filesystem. The head -50 caps the output at 50 lines so a runaway search does not scroll forever.

On a modern Linux box with ext4 or btrfs (two common Linux filesystem formats), this search is instant. On my test system with 1.2 million files in /home, find returned the first 50 matches in 180 milliseconds. That is faster than the Windows indexer can update its display after I type a single character. The reason is that find does not maintain an index. It reads the directory tree on every call, which sounds slow, but for a single-user workstation with a fast disk, it is fast enough that you do not notice.

For the common case of “I just downloaded this file, where did it go”, the pipeline is even shorter:

find ~ -mmin -10 -type f

This finds every file modified in the last 10 minutes. It is the closest thing in the Unix world to a “recent files” view, and it does not depend on a service that may or may not be running.

If you want a slightly more polished experience, install fd, a find replacement written in Rust. It has saner defaults, a colored output, and faster parallel directory walking. The command fd "*.log" /home does the same thing as the find pipeline above but with better ergonomics. On Debian and Ubuntu, install it with apt install fd-find and the binary is called fdfind to avoid a name collision with another package.

The Windows-side answer

If you actually need a search box on Windows, the open-source project Everything by voidtools is the right tool. Everything is a single 2 MB executable, no installer required, no telemetry, no account, no cloud. It indexes your NTFS volumes (the Windows filesystem format) by reading the NTFS Master File Table, a hidden index that the filesystem itself maintains. The MFT is updated by the kernel on every file change, so Everything’s index is always current without any background scanning.

The first time you launch Everything, it reads the MFT and builds a database of every file on every NTFS volume. On a 1 TB drive with 800,000 files, the initial scan takes about 2 seconds. After that, every search is sub-100ms. Typing “report” returns every file with “report” in the name, instantly, and you can filter by file type, date modified, size, and folder with a few keystrokes.

Everything has a feature called “Content Search” that does what the Windows indexer does, but on demand. You toggle it with Ctrl+F and Everything reads the file contents from disk when you press Enter. The tradeoff is that content search is not indexed, so a content search across 800,000 files takes a few seconds. For filename search, which is what most people want 90% of the time, Everything is faster than any other tool on the platform.

The free version of Everything is a download on the voidtools site. There is also a paid “Everything” tier that adds an HTTP server, an FTP server, and an ETP (Everything Transfer Protocol) client. None of those are necessary for local search. The free version is the product.

What I gave up

Switching from Windows Search to Everything was almost frictionless, but a few things changed.

Content search across files is slower. The Windows indexer keeps a precomputed hash of every file’s content. Everything does not. For a search like “phrase in any .docx”, I have to wait a few seconds, and the search can be heavy on spinning disks. For a search like “filename containing X”, Everything is dramatically faster.

Start Menu integration is gone. The Windows 11 Start Menu is supposed to be the unified search box. Everything is a separate window. You can pin Everything to the taskbar and bind it to a hotkey (Ctrl+Alt+S by default after install), which approximates the Start Menu behavior. I rebound the Win+S shortcut to launch Everything using a tiny AutoHotkey script, but that is a step.

The “recent files” view is rough. Windows remembers the last 50 files you opened per app and surfaces them in the Recent section of the Start Menu. Everything does not have an equivalent built in. You can simulate it with a search filter (dm:today for “modified today”), but the polished “I just opened this” workflow is a Windows feature, not an Everything feature.

Setup is not zero-config. The first time you run Everything, you have to tell it which volumes to index. It defaults to all fixed NTFS volumes, which is what most people want, but it is a click. On a fresh install, that click takes about 10 seconds. On a workstation that has been migrated across machines for years, expect to spend a minute pruning excluded folders.

Trade-offs

Everything is not free in time. The first time you run it, you have to read the help file to understand the syntax. The search syntax is simple, but it is not what Windows users expect. report | quarterly searches for files matching either “report” or “quarterly” by default, which is different from the implicit AND in Windows Search. You can change the default with a setting, but the new user is going to be confused for ten minutes.

There is also a versioning story. voidtools has been updating Everything for over 15 years, and the application is stable. The paid tier exists but the free tier is not crippled. That is a healthier model than most “free” Windows utilities, where the free version is a 14-day trial of the paid version. I have been running the same Everything.exe for two years across three Windows installs, and it has not asked me to register, sign in, or update.

Privacy is the third thing. Everything is a closed-source binary, so the trust model is “I trust voidtools not to phone home”. The application does not have a network listener, does not write to the registry outside its own keys, and does not show ads. The 2 MB binary can be disassembled in a weekend by anyone who cares to look. For most users, this is fine. If you handle classified material, the rule is the same as every other closed-source tool: read the network calls with Wireshark before you trust it.

For my workflow, the math is simple. Windows Search is on by default and costs me 10-20% of my CPU on a typical day. Everything runs in 30 MB of RAM, indexes 1.5 million files in 2 seconds, and returns filename searches in under 100ms. The content-search slowdown is real but it hits me once a month. The setup is 60 seconds. The Start Menu integration gap is annoying but solved with a hotkey.

What I would tell past me

If I could send a message back to the version of me who first typed into the Windows search box and waited 12 seconds for a result, I would say four things.

• The indexer is the cost, not the search. Windows Search is not slow because your disk is slow. It is slow because the indexer is fighting your disk for the same I/O. The instant you turn off Content Search, the indexer chills out, but you also lose the one feature that made the indexer worth having.
• Everything is the right tool for filenames, and you almost always want filenames. When was the last time you searched for a phrase inside a Word doc, instead of the filename of the Word doc? Almost every “I cannot find this file” moment is a filename problem. Everything solves that problem in 100ms.
• find is the right tool on Linux, and you do not need a third-party binary. The 50-year-old Unix command is faster than any modern indexed search for a single-user workstation with a fast disk. Stop installing search tools on Linux. Use find or fd.
• Stop paying the CPU tax for a feature you do not use. Turn off Cortana. Turn off Content Search. Disable the indexer on volumes you never search. None of those changes break your workflow, and they each return a measurable slice of CPU.

Bottom line: if Windows Search is the slowest part of your day, Everything is the answer. If you live in a terminal, find is the answer. The reason nobody recommends these is that they are not paid products and they do not generate affiliate links. They are just fast.