3 ms·
I remember his original post back in 2009 and being very unsatisfied. I wanted the 64-bit transition only so I could properly use my tools at work (used to wor
by BinaryIdiot 10y ago
I remember his original post back in 2009 and being very unsatisfied.
I wanted the 64-bit transition only so I could properly use my tools at work (used to work in a .Net shop). We had resharper and several other plugins that ran in the same Visual Studio process as everything else and it was fairly common to hit the memory limit of a 32-bit process and Visual Studio would essentially die until it was killed and restarted.
Sure, you can say "stop using those tools" or "they should have written them better". But at the time I was required to use most of them (it wasn't only Resharper though Resharper was pretty nice).
Today I don't have this problem anymore. But I think because of that type of issue it would still likely be worth it. Honestly I feel like they could optimize Visual Studio at the same time; it has a ton of capability but it's also incredibly large and, from my understanding, carries a TON of legacy code and resources throughout.
- ygra 10y agoI guess his original point was that while moving to 64 bit would help the few users who actually hit memory allocation limits, it would also be a monumental effort for a project the size of Visual Studio to do so, including out-of-process support for 32-bit extensions to maintain compatibility, probably rethinking designers and debugging along the way. And all that to make things actually slower and taking more memory for everyone. His argument wasn't entirely »Stop using those tools while we do nothing at all«. It was »They should have done the right thing, but we'll also work towards making Visual Studio take less memory«. Especially considering that not leading everything you might eventually ever need at once in the beginning has probably a much smaller compatibility impact than upgrading significant parts of the IDE.