What is the quantifiable benefit of 64 bit for Visual Studio Code over 32 bit

Question

I'm not a hardware guy, but I know that Visual Studio in a 64 bit version issue request was declined by Microsoft stating that a 64 bit version would not have good performance.

Two noticeable differences between the two that I feel are obvious is the code base. One began it's life in 1997, one would think that means more baggage on the Visual Studio side, less opportunities to have very modern application architecture and code and that may make it harder and possibly stuff may be built to perform on 32 bit and for some reason is not suitable for 64 bit? I don't know.

Visual Studio Code on the other hand is an modern Electron app which means it pretty much just compiled HTML. CSS and JavaScript. I'm betting making a version of Visual Studio Code has little in the way of obstructions and although performance may not be something truly noticeable, why not?

P.S.

I still would like to understand what areas may be improved in performance and if that improvement is negligible to the a developer. Any additional info or fun facts you may know would be great I would like to have as much info as possible and I will update the question with any hard facts I uncover that are not mentioned.

Mirianmirielle

I think it's necessary to mention this blog post I suppose you already read: blogs.msdn.microsoft.com/ricom/2016/01/04/… – Seldun

I found this infoq.com/news/2016/01/VS-64-bit a bit more useful and informative and I believe gives a great answer to the original question. – Littlest

Answer 1

The existence of 64-bit Visual Studio Code is largely a side-effect of the fact that the Node.js- and Chromium-based runtimes of Electron support both 32- and 64-bit architectures, not a primary design goal for the application. Microsoft developed VS Code with Electron, a framework used to build desktop applications with web technologies.

Because Electron already includes runtimes for both architectures (and for different operating systems), VS Code can provide both versions with little additional effort—Electron abstracts the differences between machines from the JavaScript code.

By contrast, Microsoft distributes much of Visual Studio as compiled binaries that contain machine-specific instructions, and the cost of rewriting and maintaining the source code for 64-bits historically outweighed any benefits. In general, a 64-bit program isn't noticeably faster to the end user than its 32-bit counterpart if it never exceeds the limitations of a 32-bit system. Visual Studio's IDE shell doesn't do much heavy-lifting—the bulk of the expensive processing in a typical workflow is performed by the integrated toolchains (compilers, etc.) which usually support 64-bit systems.

With this in mind, any benefits we may notice from running a 64-bit version of VS Code are similar to those we would see from using a 64-bit web browser. Most significantly, a 64-bit version can address more than 4 GB of memory, which may matter if we need to open a lot of files simultaneously or very large files, or if we use many heavy extensions. So—most important to us developers—the editor won't run out of memory when abused.

While this sounds like an insurance policy worth signing, even if we never hit those memory limits, remember that 64-bit applications generally consume more memory than their 32-bit counterparts. We may want to choose the 32-bit version if we desire a smaller memory footprint. Most developers may never hit that 4 GB wall.

In rare cases, we may need to choose either a 32-bit or 64-bit version if we use an extension that wraps native code like a DLL built for a specific architecture.

Any other consequences, positive or negative, that we experience from using a 64-bit version of VSCode depend on the versions of Electron's underlying runtime components and the operating system they run on. These characteristics change continuously as development progresses. For this reason, it's difficult to state in a general manner that the 32-bit or 64-bit versions outperform the other.

For example, the V8 JavaScript engine historically disabled some optimizations on 64-bit systems that are enabled today. Certain optimizations are only available when the operating system provides facilities for them.

Future 64-bit versions on Windows may take advantage of address space layout randomization for improved security (more bits in the address space increases entropy).

For most users, these nuances really don't matter. Choose a version that matches the architecture of your system, and reserve switching only if you encounter problems. Updates to the editor will continue to bring optimizations for its underlying components. If resource usage is big concern, you may not want to use a GUI editor in the first place.

Inefficacious

Answer 2

I haven't worked much on windows but have interacted with x86, x64 and ARM (Both 32-bit and 64-bit instruction set size) processors. Based on my experience, before writing the code in 64-bit format we thought: Do we really need 64-bit size instructions? If our operation can be performed within 32 bits, then why shall we need another 32 bits?

Think of it like this: You have a processor with 64-bit address and 64-bit data buses and 64-bit size registers. Almost all of the instructions of your program requires maximum 32 bits. What will you do? Well, I think there are two ways now:

1. Create a 64-bit version of your program and run all the 32-bit instructions on your 64-bit processor. (Wasting 32-bits or your processor in each instruction cycle, and filling the Program Counter with an address which is 4 bytes ahead). Your application / program which could have been executed in 256 MB of RAM now requires 512 MB, due to which other programs or processes running on the RAM will suffer.

2. Keep the program format to 32-bit and combine 2 32-bit instructions to be pushed into your 64-bit processor for execution.

Obviously, second approach will run faster with the same resources.

But yes, if your program is containing more instructions which are really 64-bit in size; For eg. Processing 4K videos (Better on 64-bit processor with 64-bit instruction set) or performing floating-points operations with up to 15 decimal digit precision, etc. Then, it is better to create 64-bit program file.

Long story in short: Try to write compact software and leverage the hardware as much as possible.

So far, what I have read Here, Here and Here; I came to know that most of the components of VS require only 32-bits instruction size.

Hope it explains.

Thanks

Leaseholder

Aside from not really answering the question, this answer spreads misinformation (I don't know who thought it was worth a bounty): 64 vs 32 bit on x86 (and I believe the same is true for ARM) has little to do with instruction size (x86 instructions have variable length anyway) - it is the pointer size that changes. And so far I have yet to see a single Application where memory consumption or avarage instruction length when compiled for x64 is anywhere near double of what you get in x86 mode. (And don't get me started about floating point part) – Ambrotype

Floating Points Operations with up to 15 decimal digit precision has nothing to do with 64-bit instructions. x86 can do it as well, and x86 also supports SIMD instructions. The main disadvantages of 32-bit x86 and 32-bit ARM are smaller address range and smaller register number. And you're mistakenly identifying 32-bit and 64-bit as instruction size, which is seriously wrong – Homologous

which could have been executed in 256 MB of RAM now requires 512 MB is another serious misinformation. Types in 64-bit programs are still the same size except for pointers and long or long long, so the increase in size is minimal unless you use a significant amount of pointers. Keep the program format to 32-bit and combine 2 32-bit instructions to be pushed into your 64-bit processor if you need to do that then SIMD would even be better. You can do operations on 8 32-bit values at the same time in a single AVX instruction, and 16 on AVX512 – Homologous

Answer 3

4 years later, in 2021, you now have:

"Microsoft's Visual Studio 2022 is moving to 64-bit" from Mary Jo Foley

It references the official publication "Visual Studio 2022" from Amanda Silver, CVP of Product, Developer Division

Visual Studio 2022 is 64-bit

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.

While Visual Studio is going 64-bit, this doesn’t change the types or bitness of the applications you build with Visual Studio. Visual Studio will continue to be a great tool for building 32-bit apps.

I find it really satisfying to watch this video of Visual Studio scaling up to use the additional memory that’s available to a 64-bit process as it opens a solution with 1,600 projects and ~300k files.
Here’s to no more out-of-memory exceptions. 🎉

Universality