JetBrains gab bekannt, dass die von Nutzern gemeldete langsame Startzeit von Rider und ReSharper unter Windows nicht vollständig auf die Architektur der beiden Tools zurückzuführen war, sondern in hohem Maße mit den Scans zusammenhing, die Microsoft Defender beim Start der Programme durchführt. Den Ergebnissen des Unternehmens zufolge verlängerte Defender den ersten Start um mehrere Dutzend Sekunden, wenn ReSharper als separater Prozess außerhalb von Visual Studio ausgeführt wurde, während die Scans anderer Tools in weniger als einer Sekunde abgeschlossen waren.
Dieses Ergebnis folgt auf die Einführung der Out-of-Process-Architektur (OOP) für ReSharper, die JetBrains entwickelt hatte, um die Auswirkungen von ReSharper auf die Reaktionsfähigkeit von Visual Studio zu verringern. Das Unternehmen stellte den OOP-Modus im Vorjahr der Öffentlichkeit zur Verfügung; in ReSharper 2026.2.1 wurde er standardmäßig aktiviert. Während interne Messungen eine allgemeine Leistungsverbesserung zeigten, deuteten Nutzerberichte auf eine Verlangsamung beim Start hin, was JetBrains zu einer detaillierteren Analyse veranlasste.
Wo trat die Verzögerung auf?
JetBrains konzentrierte sich auf die ETW-Trace-Protokolle von Microsoft Defender – ETW steht für Event Tracing for Windows – sowie auf direkte Messungen der Prozessorzeit. Das Unternehmen verwendete Ereignisse des Anbieters Microsoft-Antimalware-Engine, insbesondere die Ereignisse StreamScanRequestTask, die den Beginn und das Ende jedes Scanvorgangs protokollieren.
Die Daten zeigten, dass Dateien in schreibgeschützten Pfaden Vertrauensregeln erhalten, aufgrund derer Defender sie während des Starts weniger intensiv behandelt. Als ReSharper jedoch als separater Prozess ausgeführt wurde, wurde es vollständig gescannt, einschließlich der DLL-Bibliotheken, die aus dem Installationsordner des Benutzers geladen werden. Dadurch stieg die Scanzeit in einigen Fällen von ungefähr wenigen Sekunden auf mehrere Dutzend Sekunden.
JetBrains analysierte Dutzende Entwicklungstools und stellte große Unterschiede zwischen ihnen fest. Die Dauer eines kalten Scans lag bei JetBrains-Umgebungen und anderen Tools aus der Kategorie der Editoren ungefähr zwischen 10 und 40 Sekunden, während sie bei Microsoft-Umgebungen und anderen Editoren im selben Test unter einer Sekunde blieb. Kommandozeilenbasierte Tools benötigten ungefähr weniger als zwei Sekunden, was das Unternehmen auf die kleinen ausführbaren Dateien und die begrenzte Anzahl von DLL-Bibliotheken zurückführte.
Test und Zusammenarbeit mit Microsoft
Die Messungen wurden auf einem Dell Pro Max 16 (MA16250) mit einem Intel Core Ultra 9 285H mit 16 Kernen und 64 Gigabyte DDR5-Speicher unter Windows 11 Pro durchgeführt. Die Tools wurden in einer Hyper-V-VM ausgeführt, die mit acht vCPUs und 8 Gigabyte fest zugewiesenem Arbeitsspeicher ausgestattet war. JetBrains maß jedes Tool zehnmal und startete die virtuelle Maschine vor jedem Versuch neu, um einen Kaltstart zu simulieren und den Einfluss von Datei- und Arbeitsspeicher-Caches zu verringern.
JetBrains konnte zunächst nicht alle Scanregeln erklären, selbst nach einer Prüfung der verfügbaren Dokumentation, und wandte sich daher an das Microsoft-Team. Die Zusammenarbeit half dabei, die Faktoren zu bestimmen, die Defender dazu veranlassen, mehr Arbeit auszuführen. Außerdem half sie zu erklären, warum Rider einem intensiveren Scan unterzogen wurde als IntelliJ IDEA und ReSharper zusammen.
Microsoft veröffentlichte in Version 1.449.454.0 Änderungen an Defender, um den speziellen Fall von Rider und ReSharper OOP zu behandeln, wenn diese in einem schreibgeschützten Ordner installiert sind. JetBrains Toolbox wird jedoch standardmäßig im Pfad %LOCALAPPDATA%\Programs installiert, der das Schreiben ohne erhöhte Berechtigungen erlaubt. Daher profitiert die Installation nicht von der Verbesserung im Zusammenhang mit schreibgeschützten Ordnern. JetBrains erklärt, weiterhin die beste Vorgehensweise für die Installation von Rider über Toolbox und für Ausnahmen in Microsoft Defender zu prüfen.
Ein Tool zur Messung der Auswirkungen von Defender
JetBrains veröffentlichte das Tool Defender Performance Tool, um Entwicklern und Herausgebern zu helfen, dieselbe Untersuchung durchzuführen. Das Tool ermöglicht es, die Scanaktivität beim Start der Anwendung, beim Laden von Erweiterungen oder beim Ausführen eines Kompiliervorgangs in Echtzeit zu überwachen. Außerdem können zuvor mit New-MpPerformanceRecording aufgezeichnete Sitzungen geöffnet und später analysiert sowie CSV-Daten exportiert werden, wenn mehrere Aufzeichnungen verarbeitet werden.
JetBrains weist darauf hin, dass das Hinzufügen lokaler Ausnahmen zu Microsoft Defender in verwalteten Umgebungen durch Systemadministratoren blockiert sein kann. Daher wird dieser Schritt nicht als jederzeit verfügbare Lösung dargestellt und sollte nicht automatisch als Ersatz für die Ermittlung der Ursache der Verlangsamung oder für unternehmensweite Sicherheitsrichtlinien betrachtet werden.
Was ändert sich praktisch für Entwickler?
Dieser Fall zeigt, dass die Leistungsmessung einer Entwicklungsumgebung nicht auf die Ausführungszeit der Anwendung oder den Speicherverbrauch innerhalb des Tools selbst beschränkt ist. Die Verzögerung kann in einer parallel zum Programm arbeitenden Sicherheitsschicht auftreten, wobei ihre Auswirkungen von der Installationsmethode, dem Speicherort der Dateien und der Anzahl der beim Start geladenen Bibliotheken abhängen.
JetBrains empfiehlt, die Microsoft-Defender-Definitionen aktuell zu halten, das PowerShell-Modul für Untersuchungen zur Defender-Leistung zu verwenden und bei einer unerklärlichen Verlangsamung das neue Messwerkzeug auszuprobieren. Außerdem nennt das Unternehmen die Installation von Programmen in schreibgeschützten Ordnern, die Verwendung des Befehls Add-MpPreference zum Einrichten einer Ausnahme bei Bedarf sowie die Erstellung eines Dev Drive zum Speichern von Repositorys und Paket-Caches.
Redaktionelle Einordnung: Die wichtigste Änderung ist nicht lediglich eine interne Verbesserung in Rider oder ReSharper, sondern die Aufdeckung eines unklaren Zusammenspiels zwischen dem Design des Entwicklungstools und dem Sicherheitsmechanismus. Dennoch beziehen sich die Ergebnisse auf eine bestimmte Testumgebung, eine virtuelle Maschine und eine begrenzte Anzahl von Messungen; sie belegen daher nicht, dass alle Windows-Nutzer denselben Unterschied feststellen werden. Der praktische Wert des Beitrags liegt darin, eine Methode und ein Tool bereitzustellen, mit denen sich die Ursache vor einer Änderung der Sicherheitseinstellungen überprüfen lässt. Die Frage der Unterstützung für die Installation über JetBrains Toolbox sowie die von Systemadministratoren auferlegten Einschränkungen bleibt offen.