JetBrains reveló que el inicio lento informado por los usuarios de Rider y ReSharper en Windows no se debía por completo a la arquitectura de las dos herramientas, sino que estaba relacionado en gran medida con los análisis que Microsoft Defender realiza al ejecutarlas. Según los resultados de la empresa, Defender añadía decenas de segundos al primer inicio cuando ReSharper funcionaba como un proceso independiente fuera de Visual Studio, mientras que los análisis de otras herramientas finalizaban en menos de un segundo.
Este resultado se produce después de la adopción por parte de ReSharper de una arquitectura de ejecución fuera del proceso (Out-of-Process u OOP), una arquitectura desarrollada por JetBrains para reducir el impacto de ReSharper en la capacidad de respuesta de Visual Studio. La empresa puso el modo OOP a disposición del público el año anterior, y se activó de forma predeterminada en ReSharper 2026.2.1. Aunque las mediciones internas mostraban una mejora general del rendimiento, los informes de los usuarios comenzaron a señalar una ralentización del inicio, lo que llevó a JetBrains a realizar un análisis más detallado.
¿Dónde apareció el retraso?
JetBrains se centró en los registros de seguimiento de Microsoft Defender mediante ETW, o Event Tracing for Windows, y en mediciones directas del tiempo de procesador. La empresa utilizó eventos del proveedor Microsoft-Antimalware-Engine, en particular los eventos StreamScanRequestTask, que registran el inicio y el final de cada operación de análisis.
Los datos mostraron que los archivos ubicados en rutas protegidas contra escritura reciben reglas de confianza que hacen que Defender los trate de forma más ligera durante el inicio. Sin embargo, cuando ReSharper comenzó a funcionar como un proceso independiente, se sometió a un análisis completo, incluidas las bibliotecas DLL cargadas desde la carpeta de instalación del usuario. Como resultado, el tiempo de análisis pasó de aproximadamente unos pocos segundos a decenas de segundos en algunos casos.
JetBrains analizó decenas de herramientas de desarrollo y encontró grandes diferencias entre ellas. El tiempo de análisis en frío de los entornos de JetBrains y de otras herramientas de la categoría de editores osciló aproximadamente entre 10 y 40 segundos, mientras que permaneció por debajo de un segundo en los entornos de Microsoft y otras herramientas de edición en la misma prueba. Por su parte, las herramientas basadas en la línea de comandos tardaron aproximadamente menos de dos segundos, algo que la empresa atribuyó al menor tamaño de los ejecutables y al número limitado de bibliotecas DLL.
La prueba y la colaboración con Microsoft
Las mediciones se realizaron en un Dell Pro Max 16 (MA16250) con un procesador Intel Core Ultra 9 285H de 16 núcleos y 64 gigabytes de memoria DDR5, con Windows 11 Pro. Las herramientas se ejecutaron dentro de una máquina virtual en Hyper-V configurada con ocho unidades vCPU y 8 gigabytes de memoria fija. JetBrains midió cada herramienta diez veces y reinició la máquina virtual antes de cada intento para simular un inicio en frío y reducir el efecto de las cachés de archivos y memoria.
Al principio, JetBrains no pudo explicar todas las reglas de análisis, incluso después de revisar la documentación disponible, por lo que se puso en contacto con el equipo de Microsoft. La colaboración ayudó a identificar los factores que hacen que Defender realice más trabajo y también a explicar por qué Rider se somete a un análisis más intensivo que IntelliJ IDEA y ReSharper juntos.
Microsoft publicó modificaciones para Defender en la versión 1.449.454.0 con el fin de abordar el caso específico de Rider y ReSharper OOP cuando están instalados dentro de una carpeta protegida contra escritura. Sin embargo, JetBrains Toolbox se instala de forma predeterminada en la ruta %LOCALAPPDATA%\Programs, una ruta que permite escribir sin permisos de elevación de privilegios y que, por tanto, no se beneficia de la optimización relacionada con las carpetas protegidas. JetBrains afirma que todavía está evaluando la mejor forma de abordar la instalación de Rider mediante Toolbox y las exclusiones de Microsoft Defender.
Una herramienta para medir el impacto de Defender
JetBrains lanzó la herramienta Defender Performance Tool para ayudar a los desarrolladores y editores a realizar la misma investigación. La herramienta permite supervisar la actividad de análisis en tiempo real durante el inicio de la aplicación, la carga de extensiones o la ejecución de una compilación. También permite abrir capturas grabadas previamente mediante New-MpPerformanceRecording y analizarlas posteriormente, así como exportar datos CSV al trabajar con varias capturas.
JetBrains señala que los administradores de sistemas pueden bloquear la adición de exclusiones locales a Microsoft Defender en entornos administrados. Por ello, no presenta este paso como una solución siempre disponible, y no debería considerarse un sustituto automático de comprender la causa de la ralentización ni de aplicar las políticas de seguridad corporativas.
¿Qué cambia en la práctica para los desarrolladores?
Este caso demuestra que medir el rendimiento de un entorno de desarrollo no se limita al tiempo de ejecución de la aplicación o al consumo de memoria dentro de la propia herramienta. El retraso puede aparecer en una capa de seguridad que funciona en paralelo con el programa, y su impacto varía según el método de instalación, la ubicación de los archivos y el número de bibliotecas cargadas durante el inicio.
JetBrains recomienda mantener actualizadas las definiciones de Microsoft Defender, utilizar el módulo de PowerShell para las investigaciones de rendimiento de Defender y probar la nueva herramienta de medición cuando se observe una ralentización sin explicación. También menciona instalar los programas en carpetas protegidas contra escritura, utilizar el comando Add-MpPreference para configurar una exclusión cuando sea necesario y crear una Dev Drive para almacenar los repositorios y la caché de paquetes.
Lectura editorial: el cambio más importante no es simplemente una mejora interna en Rider o ReSharper, sino el descubrimiento de una interacción poco clara entre el diseño de la herramienta de desarrollo y el mecanismo de análisis de seguridad. No obstante, los resultados siguen estando vinculados a un entorno de prueba específico, una máquina virtual y un número limitado de mediciones; por tanto, no demuestran que todos los usuarios de Windows experimenten la misma diferencia. El valor práctico del material reside en proporcionar un método y una herramienta para verificar la causa antes de modificar la configuración de seguridad, mientras que la cuestión del soporte para la instalación de JetBrains Toolbox y las restricciones impuestas por los administradores de sistemas sigue abierta.