A JetBrains revelou que a lentidão na inicialização relatada pelos usuários do Rider e do ReSharper no Windows não era causada inteiramente pela arquitetura das duas ferramentas, mas estava em grande parte relacionada às verificações realizadas pelo Microsoft Defender quando elas eram executadas. Segundo os resultados da empresa, o Defender acrescentava dezenas de segundos à primeira inicialização quando o ReSharper funcionava como um processo separado, fora do Visual Studio, enquanto as verificações de outras ferramentas eram concluídas em menos de um segundo.
Essa conclusão veio após a adoção, pelo ReSharper, da arquitetura de execução fora do processo (Out-of-Process ou OOP), desenvolvida pela JetBrains para reduzir o impacto do ReSharper na capacidade de resposta do Visual Studio. A empresa disponibilizou o modo OOP ao público no ano anterior, e ele passou a ser ativado por padrão no ReSharper 2026.2.1. Embora as medições internas tenham mostrado uma melhoria geral no desempenho, os relatos dos usuários começaram a indicar lentidão na inicialização, levando a JetBrains a realizar uma análise mais detalhada.
Onde o atraso apareceu?
A JetBrains concentrou-se nos registros de rastreamento do Microsoft Defender por meio do ETW, ou Event Tracing for Windows, e em medições diretas do tempo de CPU. A empresa utilizou eventos do provedor Microsoft-Antimalware-Engine, especialmente os eventos StreamScanRequestTask, que registram o início e o fim de cada operação de verificação.
Os dados mostraram que arquivos localizados em caminhos protegidos contra gravação recebem regras de confiança que fazem o Defender tratá-los de forma mais leve durante a inicialização. Porém, quando o ReSharper passou a funcionar como um processo separado, foi submetido a uma verificação completa, incluindo as bibliotecas DLL carregadas da pasta de instalação do usuário. Como resultado, o tempo de verificação aumentou de aproximadamente alguns segundos para dezenas de segundos em alguns casos.
A JetBrains analisou dezenas de ferramentas de desenvolvimento e encontrou grandes diferenças entre elas. O tempo de verificação a frio dos ambientes da JetBrains e de outras ferramentas da categoria de editores variou aproximadamente entre 10 e 40 segundos, enquanto permaneceu abaixo de um segundo nos ambientes da Microsoft e em outras ferramentas de edição no mesmo teste. Já as ferramentas baseadas em linha de comando levaram aproximadamente menos de dois segundos, algo que a empresa atribuiu ao pequeno tamanho dos executáveis e ao número limitado de bibliotecas DLL.
O teste e a colaboração com a Microsoft
As medições foram realizadas em um computador Dell Pro Max 16 (MA16250) com processador Intel Core Ultra 9 285H de 16 núcleos e 64 gigabytes de memória DDR5, com Windows 11 Pro. As ferramentas foram executadas dentro de uma máquina virtual no Hyper-V, configurada com oito vCPUs e 8 gigabytes de memória fixa. A JetBrains mediu cada ferramenta dez vezes, reiniciando a máquina virtual antes de cada tentativa para simular uma inicialização a frio e reduzir o impacto do armazenamento em cache de arquivos e memória.
Inicialmente, a JetBrains não conseguiu interpretar todas as regras de verificação, mesmo após revisar a documentação disponível, por isso entrou em contato com a equipe da Microsoft. A colaboração ajudou a identificar os fatores que fazem o Defender executar mais trabalho e também a explicar por que o Rider era submetido a uma verificação mais intensa do que o IntelliJ IDEA e o ReSharper juntos.
A Microsoft lançou alterações no Defender na versão 1.449.454.0 para tratar do caso específico do Rider e do ReSharper OOP quando instalados dentro de uma pasta protegida contra gravação. No entanto, o JetBrains Toolbox é instalado por padrão no caminho %LOCALAPPDATA%\Programs, que permite a gravação sem permissões de elevação, e por isso não se beneficia da melhoria relacionada às pastas protegidas. A JetBrains afirma que ainda está avaliando a melhor forma de lidar com a instalação do Rider pelo Toolbox e com as exclusões do Microsoft Defender.
Uma ferramenta para medir o impacto do Defender
A JetBrains lançou a ferramenta Defender Performance Tool para ajudar desenvolvedores e editores a realizar a mesma investigação. A ferramenta permite monitorar a atividade de verificação em tempo real durante a inicialização do aplicativo, o carregamento de extensões ou a execução de uma compilação. Ela também permite abrir gravações previamente registradas usando New-MpPerformanceRecording e analisá-las posteriormente, além de exportar dados em CSV ao lidar com várias gravações.
A JetBrains observa que a adição de exclusões locais ao Microsoft Defender pode ser bloqueada por administradores de sistemas em ambientes gerenciados. Portanto, a empresa não apresenta essa medida como uma solução sempre disponível, e ela não deve ser tratada automaticamente como substituta da compreensão da causa da lentidão ou das políticas de proteção corporativa.
O que muda, na prática, para os desenvolvedores?
Este caso mostra que medir o desempenho de um ambiente de desenvolvimento não se limita ao tempo de execução do aplicativo ou ao consumo de memória dentro da própria ferramenta. O atraso pode aparecer em uma camada de segurança que funciona em paralelo ao programa, e seu impacto varia de acordo com o método de instalação, a localização dos arquivos e o número de bibliotecas carregadas durante a inicialização.
A JetBrains recomenda manter as definições do Microsoft Defender atualizadas, usar o módulo do PowerShell para investigações de desempenho do Defender e experimentar a nova ferramenta de medição ao notar uma lentidão inexplicada. A empresa também menciona instalar os programas em pastas protegidas contra gravação, usar o comando Add-MpPreference para configurar uma exclusão quando necessário e criar um Dev Drive para armazenar repositórios e o cache de pacotes.
Leitura editorial: a mudança mais importante não é apenas uma melhoria interna no Rider ou no ReSharper, mas a revelação de uma interação pouco clara entre o design da ferramenta de desenvolvimento e o mecanismo de verificação de segurança. Ainda assim, os resultados estão vinculados a um ambiente de teste específico, a uma máquina virtual e a um número limitado de medições; portanto, não comprovam que todos os usuários do Windows enfrentarão a mesma diferença. O valor prático do material está em oferecer um método e uma ferramenta para verificar a causa antes de modificar as configurações de proteção, enquanto a questão do suporte à instalação do JetBrains Toolbox e as restrições impostas pelos administradores de sistemas continuam em aberto.