4 ms·

When it uses even 3GB (open a 100 project sln) it’s excruciatingly slow as it is. It’s also already not limited to 4GB because it consists of multiple processes

• brokencode 6y ago
  64 bit is an improvement IMO. If the main process has more memory to work with, then it’s easier to keep things in memory and in a single process where you don’t have to incur IPC overheads. As mentioned elsewhere, the switch does increase pointer sizes, but I’d be very surprised if that is significant compared to the amount of memory used by strings and other data.
  • alkonaut 6y ago
    My point is: this no one can live with being near the memory limit in VS as it is. If you have an OOM you already waited for hours each day with the program “not responding”. I’m not saying it’s a net negative e.g due to pointer sizes (it’s very rarely the case in my experience perhaps since the x64 JIT is better than x86 so x64 is usually better or equal despite more memory use) but it also not an obvious positive and the effort must be nontrivial and should perhaps have been spent at fixing some fundamental perf issues. Like the sln mess that makes switching build configs a 15 minute wait on a large solution. They might have fixed perf issues also but I’m not optimistic. The chance for this being a general perf win is if there was overhead involved in the separation into devenv and supporting processes that can now be cut by making it all one process again. Here’s to hoping they have also done some big changes under the hood, perhaps enabled by the switch to x64.