Someday I hope it finally gets ported to x64 so that it can use more than a tiny fraction of the RAM in my desktop, instead of page thrashing all the time.
One of the areas we invested a lot in (and will continue working on) is moving a lot of our analysis and processing work out-of-process. It turns out this is a much effective way to get improved performance while taking advantage of the available RAM in the system.
There are several reasons why this is, and why it's a better solution for performance than just moving to 64bits. For one, moving to 64bits substantially increases the memory requirements to the system. For the C#/VB compiler/IDEs, it can easily double the amount of ram necessary, which can be a substantial burden on many systems. For another, when you are in a single process, you massively increase the pressure on the GC, which can lead to exacerbated GC-pauses (which are one of the single worst contributors to the IDE feeling slow or sluggish).
By moving out of proc, we can actually use less ram, have far less chance of hitting 32bit limits, and greatly improve perceived and actual latency of operations (as GCs can happen in one process without affecting the other).
We, and other teams have been using this approach with great success, and we expect to continue moving more in this direction with future updates and releases. For example, I'm doing work right now to get our indices for 'Navigate To', 'Find all References' and 'Add using' to be computed and queried outside of the main VS process. The results have been hugely successful, with the features actually running better than before, VS being even more responsive, and no excess memory usage (like we would get with 64bit).
There has been significant investigations of 64bit, and the actual empirical results of those investigations have driven our decisions. Thanks!
There seems to be some people in the IDE team who believe that a 32-bits only IDE is a feature and not a bug, including for reasons as fun as because it crashes sooner in case of memory leaks...
I guess eventually those people will move to other things and/or the market pressure will be such that we will see a 64-bits IDE. Just don't know exactly when...
We've actually done a huge amount of work investigating and addressing perf issues and working to create an architecture that can scale well. 64bits is not a panacea. And if we had simply moved to that, most people would find that their IDE was using much more ram AND behaving more sluggishly.
We decided to invest our energies in work that would actually benefit the vast majority of customers. This led to efforts that we were able to demonstrably measure as producing better experiences for people. If there's a point that 64bit will actually produce better results for people, we'll gladly move to it. Thanks!
I'm sure you carefully evaluated the pro and cons and that for now the best option for customers, also maybe given the state of your code (I've got no idea if you have problems in that area or not, but hypothetically this is the kind of thing that could have an impact) and your resources and what you want to do with such resources, is to stick to 32-bits. Because, well, you did stick to 32-bits, and it does not suck (although I've never tried to open extremely huge projects in VS)
But I also "know", and you also maybe secretly "know", that you will eventually move to 64-bits :P
I completely don't know when, and I would completely understand that neither do you, and I would also understand that there is currently no immediate plan to move. But eventually you just will.
Now, ok, I'm not 100% sure about that. But my mind would be overly blown if this does not happen (given I don't have a clue of when, I guess I could have to wait for 20 years to see if my mind is blown or not :P ). I mean come on, even iPhone programs are 64-bits now.
(You know what this reminds me of a little bit?: Mozilla not working on a multiprocess architecture as a priority a while ago...)
> but hypothetically this is the kind of thing that could have an impact
It's not hypothetical :) We've measured, and moving to 64bits is a serious issue and would directly affect many customers who could not take the RAM hit.
> But I also "know", and you also maybe secretly "know", that you will eventually move to 64-bits
At some point we probably will. but it certainly isn't now. We have ample information on the types of machines that people use for development and we've measured extensively the different approaches that are possible. Right now 64bits would be a bad decision, and going the multi-process route turned out to be quite good.
> I mean come on, even iPhone programs are 64-bits now.
That's not a reason to move. We should move to 64bits if it delivers a quality improvement and does not dramatically degrade the experience for many customers. That's not what would be the case today.
> There seems to be some people in the IDE team who believe that a 32-bits only IDE is a feature and not a bug, including for reasons as fun as because it crashes sooner in case of memory leaks...
To be clear. There are zero people on the IDE that think this. The IDE team has to deal with the reality of the situation that there are humongous solutions, and very resource constrained machines. And we've been hearing from huge numbers of developers that they absolutely do not want memory requirements to go up. Just moving to 64bits is extremely problematic. As i've already mentioned that can easily double the memory requirements for many components in VS. That's going to make VS2017 a complete non-starter for many customers.
We do not haphazardly make changes "just because". We measure measure measure, and we're loathe to do anything that we've got enormous real data on on how negative the impact could be.
The approach we've taken has actually extremely improved throughput, scaling and latency, all while actually decreasing memory usage. We're going to continue making the changes that support those goals. If/when we can have a 64 bit architecture that supports those same needs, and gives an acceptable impact on the vast majority of user machines, then we can move there.
I'm Cyrus, a developer on the C#/VB IDE team.
One of the areas we invested a lot in (and will continue working on) is moving a lot of our analysis and processing work out-of-process. It turns out this is a much effective way to get improved performance while taking advantage of the available RAM in the system.
There are several reasons why this is, and why it's a better solution for performance than just moving to 64bits. For one, moving to 64bits substantially increases the memory requirements to the system. For the C#/VB compiler/IDEs, it can easily double the amount of ram necessary, which can be a substantial burden on many systems. For another, when you are in a single process, you massively increase the pressure on the GC, which can lead to exacerbated GC-pauses (which are one of the single worst contributors to the IDE feeling slow or sluggish).
By moving out of proc, we can actually use less ram, have far less chance of hitting 32bit limits, and greatly improve perceived and actual latency of operations (as GCs can happen in one process without affecting the other).
We, and other teams have been using this approach with great success, and we expect to continue moving more in this direction with future updates and releases. For example, I'm doing work right now to get our indices for 'Navigate To', 'Find all References' and 'Add using' to be computed and queried outside of the main VS process. The results have been hugely successful, with the features actually running better than before, VS being even more responsive, and no excess memory usage (like we would get with 64bit).
There has been significant investigations of 64bit, and the actual empirical results of those investigations have driven our decisions. Thanks!