|
|
|
|
|
|
by xorblurb
3396 days ago
|
|
|
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...) |
|
|
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.