Dotnet logo

The .NET Tools Blog

Essential productivity kit for .NET developers

.NET Tools How-To's

ReSharper and Visual Studio 2022 64-bit

Good news! Microsoft has announced a new version of Visual Studio 2022. And of course, we will make sure that ReSharper is available for it to help you write better code.

The announcement from Microsoft also reveals that Visual Studio will be 64-bit. Our own Rider IDE has been 64-bit since 2017, and it’s great to see Visual Studio finally doing this too.

In this blog post, let’s look at why 64-bit matters, and what we believe it will mean for ReSharper.

Visual Studio becomes 64-bit

All of ReSharper’s features – navigation, code completion, inspections, quick fixes and refactorings, unit testing, diagramming, find usages, etc. – run inside the Visual Studio process.

Because Visual Studio is a 32-bit process, it can only use between 2.5 GB and 4 GB of memory. This memory space is shared between your project files, the .NET runtime, ReSharper, and Visual Studio’s own features, including the WPF based UI, source control, and any other installed plugins. And Visual Studio itself has added extra memory demands in recent versions, with the new SDK-style project format requiring quite some additional memory.

So even if you have a monster development machine with 128 processors, SSD drives and 1TB of memory, Visual Studio will only ever use ~4GB of memory, (roughly 2.5GB of managed memory). Memory will become cramped in larger solutions, which means the garbage collector needs to kick in more often, and throughput will suffer. Frustrating!

You can say the entire team here at JetBrains were really excited when we read that Visual Studio 2022 will become a 64-bit process. As Microsoft said:

Visual Studio 2022 will be a 64-bit application. No longer limited to ~4GB of memory in the main devenv.exe process. With a 64-bit Visual Studio on Windows, you can open, edit, run, and debug even the biggest and most complex solutions without running out of memory.

That’s great news! We hope that you are as excited about the future of Visual Studio and ReSharper as we are!

What does this mean for ReSharper?

Let’s go over some questions you may have around the new Visual Studio 2022 and ReSharper.

Will ReSharper work with the new 64-bit Visual Studio?

Yes, it will.

It’s still very early, and we’re eagerly waiting for the first preview release of Visual Studio 2022 to try things out. We’ve already done the work to build, test and run the entire ReSharper codebase on 64-bit as part of Rider. We want to work on integrating ReSharper with the new Visual Studio as soon as possible, and get ReSharper and other products ready.

Does this mean there is no more need for ReSharper out-of-process?

No, it does not.

When we deployed ReSharper as a 64-bit process to power our cross-platform IDE, Rider, we observed that fewer garbage collection cycles were needed, resulting in better memory throughput. With that knowledge, we expect that having a 64-bit process will significantly reduce memory pressure in the IDE, which will automatically lead to Visual Studio with ReSharper being more performant for memory-critical operations.

There is still room for optimization. We will keep working on ReSharper out-of-process. With Rider, we saw that running memory- and CPU-intensive operations in different processes, and wiring these processes with an asynchronous API, leads to a better development experience. For example, the ReSharper process could perform solution-wide analysis without interrupting the Visual Studio process where you are working in the editor. Also, not all our customers immediately upgrade their Visual Studio version, so having ReSharper out-of-process will benefit them as well.

Will a 64-bit Visual Studio improve ReSharper performance?

“It depends.”

A better way to look at this, as we’ve seen with the Rider, is that moving to a 64-bit process improves throughput, reduces out of memory conditions (such as heap fragmentation), and results in a smoother experience. Less memory contention means less garbage collections, which means less pauses to the UI and other tasks. This can improve overall performance and responsiveness, but it doesn’t necessarily speed up CPU intensive tasks.

For CPU-intensive tasks, we will have to wait for the first preview version of Visual Studio 2022 to see what will happen. We’re also continuing the work on ReSharper out-of-process to get more improvements in this area.

What’s the latest news on ReSharper out-of-process?

At the risk of sounding like a stuck record, we’re working on it.

As you will see in the ReSharper out-of-process issue in our tracker, there are some open items pending. This does not mean no work is being done — we’re working on it, and we’ll give details below.

With every release, we work on ReSharper performance improvements. In the latest 2021.1 version, we have:

  • Made typing in Razor files inside large solutions faster
  • Sped up editing in large files where ReSharper’s analyzers are working
  • Optimized how ReSharper deals with shared documents, so it now consumes less memory
  • Implemented performance improvements for unit testing JavaScript and TypeScript
  • Optimized data structures in our LevelDB-powered caches, reducing the memory footprint of ReSharper

We’ve heard positive feedback about these changes, give the latest ReSharper 2021.1 a try.

Any details about ReSharper out-of-process?

Now, let’s go into more detail about the original question: what’s the latest news on ReSharper out-of-process?

A lot of progress has been made. ReSharper’s internal mode can launch a ReSharper background process and load a solution. We can successfully load a full solution, a partial solution from a .slnf file, and manually unload projects, all handled outside of the Visual Studio process.

A number of tool windows are working, and we can extend existing tool windows in Visual Studio from the background process. For example, ReSharper OOP can extend the Properties tool window with some ReSharper-specific properties, you can edit them in Visual Studio, and these changes flow back to the background process.

Many actions that do not rely on the text editor, are ready to go! Solution-wide analysis runs in the background, but it can not yet show errors in the text editor.

As you might deduce from the previous paragraph, the text editor is not yet ready for out-of-process. In ReSharper, we abstract the Visual Studio editor as an ITextControl in our code base. For different Visual Studio versions, we have different abstractions, and they all integrate with the Visual Studio editor, error stripe, gutter marks, highlighters, etc. — and with the ReSharper code model.

Building Rider, we learned that the out-of-process model works best when using simple data types that are shared between the front-end and the back-end. When editing code, we pass around small bits of text and deltas. Highlightings consist of a document range, and the highlighter id. The current ITextControl is more complex than that.

We have to refactor ITextControl and decouple the frontend (Visual Studio) and backend (ReSharper OOP) parts. To make things more interesting, ITextControl has a dependency on IDocument, the abstraction that is used to manipulate text in the editor, and to update the code model in the background process.

We’re almost done with refactoring IDocument — inlay hints are the last part that we’re working on here. Once that is done, we’ll get to ITextControl, and once that is done, we’ll be able to show an editor with highlightings coming from the background process. After refactoring the abstraction to the editor, we’ll need to test that code completion still works as expected, and get to work on updating the remaining actions that depend on the editor.

We hope to be able to have a publicly available preview ready before the end of 2021. As always, we’ll keep you posted when we have anything to share. Till next time!

Discover more