ReSharper’s Out-of-Process Journey: Major Progress and Next Steps

Good news, everyone! After years of work on one of our most challenging projects, we’re excited to share major progress on ReSharper’s out-of-process implementation.

For those of you who’ve been following our journey, asking thoughtful questions, and patiently waiting for updates, we want to let you know how far we’ve come. Your continued support has been invaluable throughout this process.

To catch up on our progress, you may want to check out these posts:

2018 – Taking ReSharper out of process

2019 – Where we are with “out of process” ReSharper

2020 – Update on running ReSharper out of process

2021 – “What’s the latest news on ReSharper’s out-of-process?”

2023 – The Road to Out-of-Process ReSharper: Asynchronous Typing

2024 – Asynchronous typing enabled

We’ve been using the latest out-of-process (OOP) implementation internally for the past four weeks and are genuinely excited about the results. While not all features are fully supported and there are known issues to address, the core functionality that makes ReSharper essential to your workflow is taking shape. We’re making steady progress toward delivering a more responsive ReSharper experience.

What is OOP and why does it matter?

Performance has consistently been the number one piece of feedback we’ve received from our users over the years. Our telemetry and user surveys confirmed what many of you have been telling us: despite ReSharper’s  powerful features, the impact on Visual Studio’s responsiveness was affecting your daily workflow.

We’ve tracked multiple metrics related to perceived performance, and having analyzed the data, we realized that incremental optimizations wouldn’t be enough. We needed a fundamental architectural change that could address these core performance concerns while preserving all the productivity features you rely on.

This led us down the path of developing our new out-of-process (OOP) architecture. The fundamental goal is straightforward: keep the code that depends on the Visual Studio API within the Visual Studio process while moving ReSharper’s core functionality to a separate process. By moving the computation-heavy components to run in their own process, we’re finally able to dramatically reduce ReSharper’s impact on Visual Studio’s responsiveness. Our measurements show:

• Six times fewer noticeable pauses in the UI thread.
• ReSharper’s impact on startup reduced to under a second.
• Significantly improved typing responsiveness.

How we made it work

One of the greatest challenges of this project was implementing OOP while maintaining backward compatibility with existing features. ReSharper is one of our flagship products used by thousands of developers daily, so we cannot pause support for new language features or platform updates while working on the OOP architecture. We couldn’t simply develop a side product either – we had to perform surgery on a living, beating heart.

Modular architecture for controlled migration

To tackle this challenge, we created a system of toggles for each functional area in ReSharper. These toggles determine whether a particular capability runs inside Visual Studio or in the separate ReSharper process.

This approach lets us precisely control which parts of ReSharper have moved to the OOP model and which remain in the traditional in-process setup. We can test each component independently, ensure it works correctly in the new environment, and then gradually transition more components as development progresses. As a result, we get to maintain full functionality while systematically building out the OOP architecture.

At the same time, we needed a way for both processes to communicate seamlessly. To achieve this, we use RD, our open-source protocol, which acts as a bridge between the two environments. The toggles determine which process each component runs in, while the protocol ensures that both sides stay in sync. Each component follows a shared interface that works in both processes. If a component isn’t available in one of them, a stand-in is automatically created and injected, allowing ReSharper to function as a unified system.

Tackling UI pauses

The OOP architecture we’ve designed addresses the three main causes of frustrating noticeable UI pauses:

1. Main thread bottlenecks: A significant portion of our older codebase is not thread-safe and assumes modifications can only happen on the main thread. This consumes valuable main thread time and reduces the probability of the UI rendering quickly. Moving these operations out of process eliminates this contention.
   
2. Global content lock contention: ReSharper has historically used one global content reader-writer lock. When random activities hold onto read locks, obtaining a write lock on the main thread creates unpredictable delays. By physically relocating these activities and the content lock itself to a separate process, we can make sure these delays no longer show up in the UI.
   
3. Garbage collection overhead: Reducing the amount of work in the Visual Studio process significantly decreases memory traffic, which in turn reduces GC time and associated pauses.

Measurable typing latency improvements

To quantify the impact of moving ReSharper to OOP mode, we conducted comprehensive performance testing to measure real-world typing responsiveness.

Our measurements included six different typing tests simulating various developer typing behaviors:

• NoDelayNoOverlap tests rapid typing where each keystroke waits for the previous one to be processed, with no additional delay between keystrokes.
• MinDelayNoOverlap introduces a minimal 1ms pause between inputs while still ensuring each keystroke is fully processed before the next begins, simulating slight hesitations during typing.
• Two Isochronous tests (Isochronous150 and Isochronous300) create consistent timing patterns with fixed intervals between keystrokes of 150ms and 300ms respectively, representing different steady typing rhythms.
• The 200Dev100fc2 configuration adds natural variability to typing speed with a 200ms mean delay and 100ms standard deviation.
• Finally, our Realistic test most accurately represents typical developer typing behavior with timing patterns that closely match real-world coding sessions. 

The results consistently show that out-of-process execution significantly improves typing responsiveness across most scenarios, particularly in realistic typing conditions. In our most realistic typing scenario, median typing latency improved from 26.4ms to 16.7ms, creating a noticeably smoother editing experience.

But what does this improvement actually mean for developers in their daily work?

In practical terms, this 37% reduction in typing latency translates to a tangibly smoother coding experience. Lower latency means fewer interruptions while you type, keeping you in your flow state longer, especially during uninterrupted stretches of coding.

The difference is particularly noticeable when it comes to eliminating those frustrating moments where typing appears to freeze momentarily. We analyzed pauses on the UI thread, focusing on those lasting 100ms or more as our benchmark for disruptions that negatively impact typing flow. By counting these significant pauses across all our measurements, we found that the number of these disruptions has decreased by 600%. The 99th percentile response time dropped dramatically from 316ms in the traditional implementation to just 41ms in out-of-process mode, virtually eliminating the most severe typing interruptions that break concentration.

With our latest OOP architecture, you get all the ReSharper features you rely on, but with a much more responsive typing experience. We believe this change makes a real difference to your experience of ReSharper as a productivity enhancer.

What’s working now

The current implementation already supports most of the features you rely on daily, including:

• Core productivity features (navigation, completion, refactorings, code analysis)
• Editor enhancements (typing assistance, parameter info, inlay hints)
• Code maintenance (cleanup, formatting, generation, quick-fixes)
• Project management (solution builder, run configurations, tool windows)
• Unit testing (though debugging tests isn’t yet supported)
• ReSharper C++

Known issues

Just as in our previous status update on the OOP journey, we want to maintain complete transparency about the current limitations:

• Compatibility: ReSharper can’t run in OOP mode when dotMemory, dotTrace, or dotCover are installed.
• Broken features that need fixing include:
  • AI integration
  • Debugger features
  • DPA
  • Grammar and spelling checker 
  • Template editor
  • Structural Search and Replace 
  • Regular expression validation
  • Diagramming

What’s next

We’re almost there. After years of work and months of internal testing, we’re now just a short distance away from making ReSharper’s OOP mode available for public testing.

We’re aiming to share a build with you in a couple of months from now. If you’re eager to try it out, keep an eye on RSRP-480863. That’s where we’ll post updates and announce the preview as soon as it’s ready.

Acknowledgments

This milestone wouldn’t be possible without the remarkable work of several key team members. Special thanks to Alexander Ulitin for spearheading this project, as well as to Sergey Coox, Serge Baltic, Nikita Popov, and Denis Korneev for their essential contributions.

We’re excited about this important step toward a more responsive, efficient ReSharper experience. There’s more work ahead, but the light at the end of the tunnel is growing ever brighter.