The Antivirus Tax

For years my fingers were calibrated to Apple silicon; npm install was something that happened between two sips of coffee. Then corporate rules handed me a Windows machine.

The first install ran so long I checked whether the Wi-Fi had died. It hadn't. Nothing was broken. I had simply started paying a tax I never agreed to.

Not to the government, to Microsoft Defender. On a standard NTFS drive, Defender inspects every file synchronously, on access. One file? Unnoticeable. Eight thousand files in node_modules? You're not waiting on your SSD. You're waiting in an antivirus queue.

Most developers shrug and learn to wait. I physically can't. If a machine wastes my seconds, I'll happily spend hours to win them back: measured, automated, and open-sourced, so nobody has to do it twice.

The quiet thief

Modern development is small-file churn. git checkout rewrites thousands of files. A .NET build sprays bin/ and obj/ everywhere. npm install? Let's not even talk about it.

Every one of those files gets scanned before your tools are allowed to touch it. And the cost is invisible: no progress bar ever says waiting for Defender. Your machine just feels slow.

It isn't slow. It's queuing.

The fix Windows ships and nobody uses

Windows 11 quietly ships the remedy: Dev Drive, a ReFS volume where Defender switches into asynchronous performance mode. Your files still get scanned; your tools just stop waiting for the verdict. Protection stays. Blocking goes.

The catch: setting one up properly means partitioning decisions, Hyper-V cmdlets, trust flags, remount tasks. Which is why most developers have never seen one.

I compressed all of it into one command:

.\Create-DevDrive.ps1

The script prints its plan, waits for your Y/N, and builds a VHD-backed Dev Drive: a single .vhdx file living on C:. No repartitioning. Nothing existing is touched. Delete the file later and it's as if it never happened.

Numbers, not vibes

Same machine. Same physical NVMe; the Dev Drive is just a file on C:. The only variable is Defender's scan mode. 8,000 small files, two timed runs averaged, warm-up run discarded:

Write / create−31%

Read−47%

Delete−62%

Total−39.6%

Deletes run 62% faster. The full write-read-delete cycle: 39.6% faster. And that's the humble VHD variant; a native Dev Drive partition typically stretches the gap further.

Run it on your own hardware; the benchmark script ships in the repo. If your numbers beat mine, I genuinely want to hear about it.

Paranoia, engineered in

I don't trust scripts that touch storage. Including mine. So this one refuses to run unless six guard checks pass (elevation, Windows build, free space, size floor, Hyper-V cmdlets present, no VHD already in the way), and it never formats anything that exists.

Make it stick

Two more minutes and your whole toolchain benefits:

1. Survive reboots: Register-DevDriveAutoMount.ps1 adds a logon task that re-mounts the drive.
2. Move the churn: point your package caches (npm, NuGet, pip, Cargo, Maven, Gradle) at the new volume, and clone your repos there.
3. Keep the tools on C:: IDE, SDKs, runtimes stay put. Only the workload files move.

That's the whole trick: the I/O-heavy 90% of your day lands on the volume built for it.

---

The scripts, the benchmark, and the fsutil proof that Defender really runs async are all in the repo: win11-dev-drive-setup.

This is the kind of engineering I enjoy most: find an invisible tax, measure it honestly, delete it, and leave behind something anyone can run in one command. If that's your kind of engineering too, my inbox is open.