[xorblurb]

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...

[Metasyntactic]

Hi Xorblurb :)

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!

[xorblurb]

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...)

[Metasyntactic]

> 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.