{"id":5087,"date":"2026-09-10T00:44:48","date_gmt":"2026-09-10T03:44:48","guid":{"rendered":"https:\/\/tucumandevelopers.com\/index.php\/2026\/09\/10\/why-rider-and-resharper-were-slow-to-start-and-how-microsoft-helped-fix-the-problem\/"},"modified":"2026-09-10T00:44:48","modified_gmt":"2026-09-10T03:44:48","slug":"why-rider-and-resharper-were-slow-to-start-and-how-microsoft-helped-fix-the-problem","status":"publish","type":"post","link":"https:\/\/tucumandevelopers.com\/index.php\/2026\/09\/10\/why-rider-and-resharper-were-slow-to-start-and-how-microsoft-helped-fix-the-problem\/","title":{"rendered":"Why Rider and ReSharper Were Slow to Start, and How Microsoft Helped Fix the Problem"},"content":{"rendered":"
\n
\n
\n
\n

.NET Tools<\/a> ReSharper Platform<\/a> Rider<\/a><\/p>\n

\n<\/p><\/div>\n

When we launched ReSharper\u2019s out-of-process (OOP) architecture<\/a>, users reported slower startup times for IDEs using ReSharper on Windows. After profiling, the cause surprised us: Microsoft Defender was scanning our process for longer than we expected. This post is about what we found, what we learned working with Microsoft, and a tool we built that allows others to run the same investigation.<\/p>\n

An unexpected factor in startup performance<\/h2>\n

Performance of our tools has consistently been the number one subject of feedback we\u2019ve received from our users over the years. Our telemetry and user surveys confirmed what many of you have been telling us: Despite ReSharper\u2019s powerful features, the impact on Visual Studio\u2019s responsiveness was affecting your daily workflow. This led us down the path of developing our new out-of-process (OOP) architecture<\/a>. We originally launched OOP mode for the public last year. (Now, thanks to these investigations, as of 2026.2.1 it is enabled by default.) In general, our telemetry indicated improved performance. However, at some point, we noticed something unexpected \u2013 customers started reporting slower startup times. After a few profiling iterations, the collected data pointed to an unexpected source of latency: Microsoft Defender.<\/p>\n

It turned out that processes in write-protected paths receive wider trust rules. Microsoft Defender barely touches those processes during startup \u2013 scanning takes a couple of seconds, even when ReSharper loads their DLLs from the user installation directory. But the moment ReSharper started running as a separate process, Defender scanned it in full, adding tens of seconds to first launch (see the chart below).<\/p>\n

\n
ReSharper In-Process vs Out-of-Process<\/figcaption><\/figure>\n<\/div>\n

This triggered our curiosity and sent us down a rabbit hole. We started analyzing Microsoft Defender ETW (Event Tracing for Windows<\/a>) logs across dozens of developer tools, and the findings were striking: Some tools get scanned for 30+ seconds at startup while others finish in under a second, as we had observed above. We obviously wanted to learn the reasons behind that and find ways to speed up startup for JetBrains tools. An ambitious project, but we were up for the challenge!<\/p>\n

The first thing we needed was to set up a repeatable measurement process. That way we could share it with other teams in JetBrains, and with our colleagues from Microsoft to have a productive conversation. We are grateful for all Microsoft\u2019s explanations, openness, and willingness to help us with this investigation.<\/p>\n

Measuring the impact<\/h2>\n

We tracked the activity of Microsoft Defender in two ways: Microsoft Defender ETW logs (as mentioned above) and direct CPU time measurements. We found the two methods to be roughly equivalent for our scenario. If you\u2019re interested in the distinction, see our GitHub readme for more info<\/a>.<\/p>\n

Microsoft Defender, like many other Windows components, uses ETW. It emits events under the Microsoft-Antimalware-Engine provider. Microsoft provides a PowerShell module for Defender-related performance investigations<\/a> that uses this provider. It has two cmdlets: New-MpPerformanceRecording<\/a> to collect a trace, and Get-MpPerformanceReport<\/a> to analyze it.<\/p>\n

In our scenarios, most slowdowns came from Microsoft Defender\u2019s scan events. The Microsoft-Antimalware-Engine\/StreamScanRequestTask ETW events report each scan\u2019s Start <\/em>and End <\/em>time, representing how long Defender spent scanning that stream in real-world elapsed time. The data we gathered showed us clearly how Defender was impacting our tool\u2019s startup wall time.<\/p>\n

Methodology<\/h3>\n

Performance measurements were run on a Dell Pro Max 16 (MA16250) laptop with an Intel Core Ultra 9 285H (16 cores) processor and 64 GB of DDR5-class memory. The host ran Windows 11 Pro. The workload was executed inside a Hyper-V VM configured with 8 vCPUs and 8 GB of static RAM. Each tool was measured 10 times.<\/p>\n

As per standard best practices when measuring performance, we rebooted our VM before each measurement to simulate a cold start. This reduced observed file and memory caching effects on our results.<\/p>\n

The charts below show the mean scan time with standard deviation error bars.<\/p>\n

Results of the experiment<\/h2>\n
\n
<\/figure>\n<\/div>\n
\n
<\/figure>\n<\/div>\n
\n
<\/figure>\n<\/div>\n
\n
<\/figure>\n<\/div>\n

As you can see, we measured a variety of development tools, and there were clear differences in the amount of time Defender took to scan them: <\/p>\n