Finally after all these years of waiting Visual Studio 2022 will run in a 64 bits process on 64 bits machines! As a consequence the effective process address space of the main Visual Studio process devenv won’t be limited anymore to 2GB.
The actual problem with devenv being a 32 bits process, is that large VS solutions (say 10K+ classes) tend to saturate the 2GB limit. This leads to substantial slow down and even to some OutOfMemoryException crashes. When working on a large solution, it is not uncommon to restart Visual Studio several times a day.
64-bit computing started to trickle down to the Personal Computer desktop from 2003 onward. But why did it take almost 2 decades to get a 64 bits version of VS? In this post I’d like to highlight some publicly available history facts that might shed light on the history.
The Visual Studio x64 migration is a massive move
Visual Studio has been around for more than two decades and as a result, the IDE implementation mixes a few different technical stacks: native code, managed code (and even UI stacks like WinForms and WPF). To communicate these different layers use COM Interop and it was certainly quite a challenge to manage the migration of this ‘glue’ layer from 32 bits to 64 bits.
By looking for the word Interop under C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7 118 DLLs are matched.
Some quick statistics obtained with NDepend over all of the 1 675 Visual Studio 2019 assemblies shows 198 192 managed types and 1 517 309 methods! The stats diff is against Visual Studio 2017.
Among the 198K types a code query based on System.Runtime.InteropServices.GuidAttribute matches 12 024 COM interop interfaces and classes visible to COM!
When working with .NET AnyCPU code, the underlying 32 or 64 bits runtime architecture is transparent. But when dealing with COM interop, the size of pointers matter. Let’s remind that IntPtr.Size is 4 bytes in a 32 bits process and 8 bytes in a 64 bits process as long as the “Prefer 32-bit” option is turned off. Thus when migrating from x86 to x64, COM interop signature and structure alignment/marshalling change. Given the scale of the Visual Studio code base, this certainly leads to a lot of migration work.
Out-of-proc to the rescue
Since the introduction of Roslyn within Visual Studio 2015, the trend has been to process more and more IDE data in child processes whose parent is the main devenv process. This architecture helps a lot in reducing the memory pressure within devenv.exe. Hence it certainly contributed to postpone the x64 migration until now.
Notice that it is especially worth running out-of-proc the languages services (intellisense, analysis, compiler…). These services need to have a somehow holistic view of the VS solution, or at least of all VS projects loaded. As a consequence they tend to consume an amount of memory linear with the amount of code loaded.
Will moving an application from 32-bit to 64-bit potentially reduce performance?
Moving to 64 bits doesn’t necessarily mean more performance. Rico Mariani was a principal Visual Studio performance engineer until March 2017. Rico is now working at Facebook since 2017 after 28 years of engineering at Microsoft. Rico exposed some technical reasons about why moving the IDE to 64 bits could not help much, but could also degrade performance. He wrote several detailed articles, like here on InfoQ in 2016 or here on his blog in 2009.
Here are some Rico Mariani’s quotes concerning the potential performance hits:
- “Your pointers will get bigger; your alignment boundaries get bigger; your data is less dense; equivalent code is bigger. You will fit less useful information into one cache line, code and data, and you will therefore take more cache misses. “
- “Most of Visual Studio does not need and would not benefit from more than 4G of memory. Any packages that really need that much memory could be built in their own 64-bit process and seamlessly integrated into VS without putting a tax on the rest. “
- “most of the time, staying with 32-bit and reducing the amount of memory being consumed will have a much larger impact for both the application and the operating systems as a whole”
Let’s note that some of these points might be outdated. Nowadays 64 bits processors handle 64 bits registers as fast as 32 bits ones. However some points will be still relevant: structure’s values with pointers will necessarily be larger thereby reducing the amount of CPU cache available for other things.
It will be interesting to look at the first previews benchmarks. Let’s hope that the Visual Studio 2022 migration is made in a way that will counter these predictions!
The 64 bits move will force extensions to be updated
This x64 move is sensitive because it de-facto breaks all the thousands of Visual Studio extensions. The extensions that don’t compile against AnyCPU and/or that consume some interop API will have to undergo a migration. But all the other ones, even the AnyCPU ones, will have to be recompiled against the new VS2022 APIs and the fully tested. On a side note, as the team leader of a Visual Studio extension I’d like to praise the remarkable effort of the Visual Studio team in accompanying all of us during this move. Thank you!
Resharper and Rider
There are 4 facts about the Visual Studio Resharper extension that makes it special:
- Although VisualStudio refactorings based on Roslyn can nowadays sustain the comparison with the Resharper ones as I explained here, Resharper is still quite a popular extension.
- Resharper has its own language services (it doesn’t use the Roslyne ones) that necessarily consume significant memory.
- Resharper still runs within the devenv.exe process. The Resharper team has been working for several years on externalizing the bulk of its processing out of process but the work is still in progress (May 2021).
- Jetbrains built Rider first released in August 2017, a competitor .NET IDE based on Resharper. Rider has no 32 bits memory space limitation. As a consequence it is faster than Visual Studio hosting Resharper, especially on large solutions. Interestingly enough Rider use a similar multi-processes approach, here is a 2018 quote from Jetbrains: “The IDE is just the UI and a host process, and a lot of the heavy lifting happens in the child processes that are spawned, and this works wonders for performance.”. In this other 2019 post, the Jetbrains engineer explains in detail why Resharper works seamlessly out-of-proc in the Rider context, and why it is difficult to run it out-of-proc in the Visual Studio context. Basically the IDE architectures are quite different and with Rider they own both sides of the interface contract.
The result of all these facts combined is often slow IDE experience for Visual Studio + Resharper users that works on a large solution. Also by reading comments on Visual Studio vs. Rider articles, it is ironic to read that some Resharper users moved to Rider mostly for performance reasons. I have no idea to which extent the Resharper memory consumption and Rider concurrence played a role in the VS2022 x64 move decision, but it makes sense to assume it mattered, even a bit.
Preparing the future
Visual Studio 2022 will still run on the good old (and sealed) .NET Framework 4.x. Moving it to x64 can be seen as pre-step to run the next major VS versions on .NET 8, 9 or 10 in 2023, 2024 or 2025. This way the IDE will benefit from all the massive performance improvement effort put into the new runtimes.
Also, most of the hundreds of the Visual Studio UIs controls are WPF based. WPF runs only on Windows and there is no plan to make WPF a multi-platform technology. As a consequence, both the WPF legacy and the COM interop legacy prevent to easily port Visual Studio on Linux and MacOS.
On the other hand .NET is nowaday a complete multi-platforms technology. Both Visual Studio Code and Visual Studio for Mac – initially Xamarin Studio – help address the lack of Visual Studio support for non-Windows OS. However it is reasonable to imagine that once Visual Studio will run on .NET 8, 9 or 10, it will be time for Microsoft to migrate all the UI and COM interops to make it a multi-OS IDE. Will the multi-OS UI technology chosen be Xamarin.Forms? or another one? Certainly it is a bit too early to guess.
Summary
There were many solid reasons for Visual Studio to remain within a 32 bits process for years. However the move to x64 is now inevitable to prepare the future. The entire community of Visual Studio users acclaim this move and we are all awaiting with great expectation the first public previews.
Good move