JetBrains a révélé que la lenteur du démarrage signalée par les utilisateurs de Rider et ReSharper sous Windows n’était pas entièrement due à l’architecture des deux outils, mais qu’elle était en grande partie liée aux analyses effectuées par Microsoft Defender lors de leur lancement. Selon les résultats de l’entreprise, Defender ajoutait des dizaines de secondes au premier démarrage lorsque ReSharper fonctionnait comme un processus séparé de Visual Studio, tandis que les analyses d’autres outils se terminaient en moins d’une seconde.
Cette conclusion intervient après l’adoption par ReSharper d’une architecture d’exécution hors processus (Out-of-Process ou OOP), conçue par JetBrains pour réduire l’impact de ReSharper sur la réactivité de Visual Studio. L’entreprise a rendu le mode OOP public l’année précédente, et celui-ci est devenu activé par défaut dans ReSharper 2026.2.1. Alors que les mesures internes montraient une amélioration générale des performances, les rapports des utilisateurs ont commencé à faire état d’un ralentissement du démarrage, ce qui a incité JetBrains à mener une analyse plus détaillée.
Où le retard est-il apparu ?
JetBrains s’est concentrée sur les journaux de trace de Microsoft Defender via ETW, ou Event Tracing for Windows, ainsi que sur des mesures directes du temps processeur. L’entreprise a utilisé des événements du fournisseur Microsoft-Antimalware-Engine, en particulier les événements StreamScanRequestTask, qui enregistrent le début et la fin de chaque opération d’analyse.
Les données ont montré que les fichiers situés dans des chemins protégés contre l’écriture bénéficient de règles de confiance qui permettent à Defender de les traiter plus légèrement lors du démarrage. En revanche, lorsque ReSharper a commencé à fonctionner comme un processus séparé, il a fait l’objet d’une analyse complète, y compris les bibliothèques DLL chargées depuis le dossier d’installation de l’utilisateur. Par conséquent, la durée de l’analyse est passée d’environ quelques secondes à plusieurs dizaines de secondes dans certains cas.
JetBrains a analysé des dizaines d’outils de développement et a constaté d’importantes différences entre eux. La durée d’une analyse à froid des environnements JetBrains et d’autres outils de la catégorie des éditeurs se situait approximativement entre 10 et 40 secondes, tandis qu’elle restait inférieure à une seconde pour les environnements Microsoft et d’autres outils d’édition lors du même test. Les outils reposant sur la ligne de commande prenaient environ moins de deux secondes, ce que l’entreprise a attribué à la petite taille des exécutables et au nombre limité de bibliothèques DLL.
Tests et collaboration avec Microsoft
Les mesures ont été effectuées sur un Dell Pro Max 16 (MA16250) équipé d’un processeur Intel Core Ultra 9 285H à 16 cœurs et de 64 gigaoctets de mémoire DDR5, sous Windows 11 Pro. Les outils ont été exécutés dans une machine virtuelle Hyper-V dotée de huit unités vCPU et de 8 gigaoctets de mémoire fixe. JetBrains a mesuré chaque outil dix fois, en redémarrant la machine virtuelle avant chaque tentative afin de simuler un démarrage à froid et de réduire l’effet de la mise en cache des fichiers et de la mémoire.
Au début, JetBrains n’a pas pu expliquer toutes les règles d’analyse, même après avoir consulté la documentation disponible, et a donc contacté l’équipe de Microsoft. Cette collaboration a permis d’identifier les facteurs qui poussent Defender à effectuer davantage de travail, ainsi que d’expliquer pourquoi Rider faisait l’objet d’une analyse plus intensive qu’IntelliJ IDEA et ReSharper réunis.
Microsoft a publié des modifications de Defender dans la version 1.449.454.0 afin de traiter le cas particulier de Rider et de ReSharper OOP lorsqu’ils sont installés dans un dossier protégé contre l’écriture. Cependant, l’installation de JetBrains Toolbox s’effectue par défaut dans le chemin %LOCALAPPDATA%\Programs, un chemin qui autorise l’écriture sans élévation de privilèges et qui ne bénéficie donc pas de l’amélioration liée aux dossiers protégés. JetBrains indique qu’elle évalue encore la meilleure manière de gérer l’installation de Rider via Toolbox et les exclusions de Microsoft Defender.
Un outil pour mesurer l’impact de Defender
JetBrains a lancé l’outil Defender Performance Tool afin d’aider les développeurs et les éditeurs à mener la même investigation. L’outil permet de surveiller en temps réel l’activité d’analyse lors du démarrage de l’application, du chargement des extensions ou de l’exécution d’une compilation. Il permet également d’ouvrir des captures enregistrées au préalable à l’aide de New-MpPerformanceRecording et de les analyser ultérieurement, ainsi que d’exporter des données CSV lors du traitement de plusieurs captures.
JetBrains souligne que l’ajout d’exclusions locales à Microsoft Defender peut être interdit par les administrateurs systèmes dans les environnements gérés. Cette étape n’est donc pas présentée comme une solution toujours disponible et ne doit pas être considérée automatiquement comme une alternative à la compréhension de la cause du ralentissement ou aux politiques de sécurité de l’entreprise.
Qu’est-ce qui change concrètement pour les développeurs ?
Ce cas montre que la mesure des performances d’un environnement de développement ne se limite pas au temps d’exécution de l’application ou à la consommation mémoire de l’outil lui-même. Le retard peut apparaître dans une couche de sécurité qui fonctionne parallèlement au programme, et son impact varie selon la méthode d’installation, l’emplacement des fichiers et le nombre de bibliothèques chargées au démarrage.
JetBrains recommande de maintenir les définitions de Microsoft Defender à jour, d’utiliser le module PowerShell dédié aux investigations sur les performances de Defender et d’essayer le nouvel outil de mesure lorsqu’un ralentissement inexpliqué est constaté. L’entreprise mentionne également l’installation des programmes dans des dossiers protégés contre l’écriture, l’utilisation de la commande Add-MpPreference pour configurer une exclusion lorsque cela est nécessaire, ainsi que la création d’un Dev Drive pour stocker les dépôts et le cache des paquets.
Lecture éditoriale : le changement le plus important n’est pas simplement une amélioration interne de Rider ou de ReSharper, mais la mise en évidence d’une interaction peu claire entre la conception de l’outil de développement et le mécanisme d’analyse de sécurité. Toutefois, les résultats restent liés à un environnement de test précis, à une machine virtuelle et à un nombre limité de mesures ; ils ne prouvent donc pas que tous les utilisateurs de Windows subiront la même différence. La valeur pratique de cet article réside dans la fourniture d’une méthode et d’un outil permettant de vérifier la cause avant de modifier les paramètres de sécurité, tandis que la question de la prise en charge de l’installation de JetBrains Toolbox et les restrictions imposées par les administrateurs systèmes restent ouvertes.