I'm a dev on the "IDE team" :)
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!
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...)
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.