Die Antivirus-Steuer

Jahrelang waren meine Finger auf Apple Silicon kalibriert; npm install passierte irgendwo zwischen zwei Schlucken Kaffee. Dann drückte mir die Firmen-IT eine Windows-Maschine in die Hand.

Der erste Install lief so lange, dass ich nachgesehen habe, ob das WLAN tot ist. War es nicht. Kaputt war auch nichts. Ich hatte nur angefangen, eine Steuer zu zahlen, der ich nie zugestimmt hatte.

Nicht ans Finanzamt, an Microsoft Defender. Auf einem gewöhnlichen NTFS-Laufwerk prüft Defender jede Datei synchron, beim Zugriff. Eine Datei? Merkst du nicht. Achttausend Dateien in node_modules? Dann wartest du nicht auf deine SSD. Du stehst beim Virenscanner an.

Die meisten Entwickler zucken mit den Schultern und lernen zu warten. Ich kann das körperlich nicht. Wenn eine Maschine meine Sekunden verschwendet, investiere ich mit Freude Stunden, um sie zurückzuholen: gemessen, automatisiert und als Open Source, damit es niemand zweimal machen muss.

Der stille Dieb

Moderne Entwicklung ist ein Dauerfeuer kleiner Dateien. git checkout schreibt Tausende Dateien neu. Ein .NET-Build sprüht bin/ und obj/ in jede Ecke. npm install? Reden wir lieber gar nicht erst drüber.

Jede einzelne dieser Dateien wird gescannt, bevor deine Tools sie anfassen dürfen. Und die Kosten sind unsichtbar: Kein Fortschrittsbalken sagt jemals warte auf Defender. Deine Maschine fühlt sich einfach langsam an.

Sie ist nicht langsam. Sie steht an.

Der Fix, den Windows mitliefert und den keiner nutzt

Windows 11 liefert das Gegenmittel still und leise gleich mit: Dev Drive, ein ReFS-Volume, auf dem Defender in den asynchronen Performance-Modus schaltet. Deine Dateien werden weiterhin gescannt; deine Tools warten nur nicht mehr aufs Urteil. Der Schutz bleibt. Das Blockieren verschwindet.

Der Haken: Ein Dev Drive sauber aufzusetzen heißt Partitionierungsentscheidungen, Hyper-V-Cmdlets, Trust-Flags, Remount-Tasks. Genau deshalb haben die meisten Entwickler noch nie eines gesehen.

Ich habe das Ganze in einen einzigen Befehl gepackt:

.\Create-DevDrive.ps1

Das Skript zeigt dir seinen Plan, wartet auf dein Y/N und baut ein VHD-basiertes Dev Drive: eine einzelne .vhdx-Datei, die auf C: liegt. Kein Umpartitionieren. Nichts Bestehendes wird angefasst. Lösch die Datei später, und es ist, als wäre nie etwas gewesen.

Zahlen statt Bauchgefühl

Gleiche Maschine. Gleiche physische NVMe; das Dev Drive ist ja nur eine Datei auf C:. Die einzige Variable ist der Scan-Modus von Defender. 8.000 kleine Dateien, zwei gestoppte Läufe gemittelt, Warm-up-Lauf verworfen:

Löschen läuft 62 % schneller. Der komplette Schreib-Lese-Lösch-Zyklus: 39,6 % schneller. Und das ist die bescheidene VHD-Variante; eine native Dev-Drive-Partition legt typischerweise noch eine Schippe drauf.

Lass es auf deiner eigenen Hardware laufen; das Benchmark-Skript liegt mit im Repo. Wenn deine Zahlen meine schlagen, will ich davon hören, ehrlich.

Paranoia ab Werk

Ich traue keinem Skript, das an meinen Speicher geht. Auch meinem eigenen nicht. Deshalb verweigert dieses hier den Dienst, solange nicht sechs Guard-Checks bestanden sind (Adminrechte, Windows-Build, freier Speicherplatz, Mindestgröße, Hyper-V-Cmdlets vorhanden, keine VHD bereits im Weg), und es formatiert niemals etwas, das schon existiert.

Damit es sich richtig auszahlt

Zwei Minuten mehr, und deine ganze Toolchain profitiert:

1. Reboots überleben: Register-DevDriveAutoMount.ps1 richtet einen Logon-Task ein, der das Laufwerk wieder einhängt.
2. Den Churn umziehen: leg deine Package-Caches (npm, NuGet, pip, Cargo, Maven, Gradle) auf das neue Volume und clone deine Repos gleich dort.
3. Die Tools bleiben auf C:: IDE, SDKs, Runtimes bleiben, wo sie sind. Nur die Workload-Dateien ziehen um.

Das ist der ganze Trick: Die I/O-lastigen 90 % deines Tages landen auf dem Volume, das genau dafür gebaut ist.

Die Skripte, der Benchmark und der fsutil-Beweis, dass Defender wirklich async läuft, liegen alle im Repo: win11-dev-drive-setup.

Das ist die Sorte Engineering, die mir am meisten Spaß macht: eine unsichtbare Steuer finden, sie ehrlich messen, sie streichen und etwas hinterlassen, das jeder mit einem einzigen Befehl ausführen kann.