As far as I know, the philosophy in VS has been to move extensions out of the devenv process for resiliency, but having done so, multiple 32 bit processes end up being more compact than a single 64 bit process. The lack of 64 bit devenv has always raised eyebrows since almost everything else is these days, although it is a legitimate question to ask why an IDE really needs 4Gb of RAM. Things like compilation are going to be done by a large number of child processes, not the IDE process.
A 32bit address space can cause problems even before your app has allocated 4gb of memory.
Depending on how you allocate and free memory, you might get a fragmented heap and not have room to allocate large chunks of memory anymore, well before you’ve allocated all addressable memory.
If you want your editor to do semantic code analysis the amount of derived data (types, use-def chains, etc) you use turns out to be substantial. This is because you need to process much larger inputs than an editor (editor can show a single file, semantic code analysis requires some knowledge about all files in the project and it’s dependencies) and the data is complex (types are trees or graphs, scopes are hash maps, etc).
It’s possible to reduce ram consumption significantly by spilling rarely used data to disk and being smart with lazily realizing only absolutely required bits of info. But, if you just naively code ide stuff without optimizing for memory usage specifically, you’ll end up in gigabytes range.
The point you are missing is that VS has been heavily extension based, so “semantic code analysis” probably shouldn’t be a part of the main process to start with.
I don’t know the current state, but at least n years ago extensions were run in-process. I think (but don’t know exactly) that that was the story with JetBrains Rider: Resharper really suffered from being in the same process as Studio itself, so they came up with idea of moving the brains to a separate process, and, hey, if the brains are a separate CLR app, why not bridge then to existing Java UI of IntelliJ?
These docs seems to imply that everything is still in the same process?
When your Visual Studio solution grows large, two code analysis engines (ReSharper and Roslyn) working simultaneously can reach the memory limit of the 32-bit process that they share.
It’s fuzzy. Plugins do technically run in-process, but even all but the most trivial of Microsoft’s own plugins are narrow shims that then communicate with the actual plugin core that’s off running in a COM apartment or an equivalent IPC mechanism. I’m not entirely sure how much the cart is pulling the horse there (i.e., whether VS being 32-bits has caused that, or whether their desire for the increased reliability of having out-of-process plugins has enabled VS to stay 32-bit), but that’s where you’re seeing that disconnect.
I hope Visual Studio devs have a good migration plan for extensions. I assume for most of them a “simple” rebuild is enough, but since that needs to be done by the authors, one could expect a lot of extensions will be broken for a while.
Woah, it still wasn’t 64-bit?! o_0
Hmm. VS for Mac being based on MonoDevelop, will that work end up in the open MonoDevelop repo? Would MonoDevelop on GTK receive less attention now?
For some background:
https://web.archive.org/web/20170310075121/https://blogs.msdn.microsoft.com/ricom/2015/12/29/revisiting-64-bit-ness-in-visual-studio-and-elsewhere/
As far as I know, the philosophy in VS has been to move extensions out of the devenv process for resiliency, but having done so, multiple 32 bit processes end up being more compact than a single 64 bit process. The lack of 64 bit devenv has always raised eyebrows since almost everything else is these days, although it is a legitimate question to ask why an IDE really needs 4Gb of RAM. Things like compilation are going to be done by a large number of child processes, not the IDE process.
A 32bit address space can cause problems even before your app has allocated 4gb of memory.
Depending on how you allocate and free memory, you might get a fragmented heap and not have room to allocate large chunks of memory anymore, well before you’ve allocated all addressable memory.
I am not sure if this is a good thing or a bad one. Why would an editor require 4G or RAM?
If you want your editor to do semantic code analysis the amount of derived data (types, use-def chains, etc) you use turns out to be substantial. This is because you need to process much larger inputs than an editor (editor can show a single file, semantic code analysis requires some knowledge about all files in the project and it’s dependencies) and the data is complex (types are trees or graphs, scopes are hash maps, etc).
It’s possible to reduce ram consumption significantly by spilling rarely used data to disk and being smart with lazily realizing only absolutely required bits of info. But, if you just naively code ide stuff without optimizing for memory usage specifically, you’ll end up in gigabytes range.
Did some interesting ultra high-level benchmarks here: https://github.com/rust-analyzer/rust-analyzer/issues/7330#issuecomment-823209678
The point you are missing is that VS has been heavily extension based, so “semantic code analysis” probably shouldn’t be a part of the main process to start with.
I don’t know the current state, but at least n years ago extensions were run in-process. I think (but don’t know exactly) that that was the story with JetBrains Rider: Resharper really suffered from being in the same process as Studio itself, so they came up with idea of moving the brains to a separate process, and, hey, if the brains are a separate CLR app, why not bridge then to existing Java UI of IntelliJ?
These docs seems to imply that everything is still in the same process?
https://www.jetbrains.com/help/resharper/Speeding_Up_ReSharper.html
Not sure how up to date they are.
It’s fuzzy. Plugins do technically run in-process, but even all but the most trivial of Microsoft’s own plugins are narrow shims that then communicate with the actual plugin core that’s off running in a COM apartment or an equivalent IPC mechanism. I’m not entirely sure how much the cart is pulling the horse there (i.e., whether VS being 32-bits has caused that, or whether their desire for the increased reliability of having out-of-process plugins has enabled VS to stay 32-bit), but that’s where you’re seeing that disconnect.
AFAIK this 32-bit was a huge problem if you used static analysis tools like ReSharper
I hope Visual Studio devs have a good migration plan for extensions. I assume for most of them a “simple” rebuild is enough, but since that needs to be done by the authors, one could expect a lot of extensions will be broken for a while.