Slashdot Mirror
Microsoft Declines To Make a 64-Bit Visual Studio (uservoice.com)
OhPlz writes: A request was made back in 2011 for Microsoft to provide a 64 bit version of Visual Studio to address out-of-memory issues. After sitting on the request for all that time, Microsoft is now declining it, stating that it would not be good for performance.
After almost five years, the request received 3,127 votes on the UserVoice forum for Visual Studio. Microsoft instead recommended the vsFunnel extension to optimize memory by filtering low-priority projects, adding "we highly value your feedback." They cited a December MSDN post that had argued "smaller is faster," and that no performance benefits would be realized for users whose code and data already fit into a 32-bit address space, while most other issues could be addressed with better data design.
After almost five years, the request received 3,127 votes on the UserVoice forum for Visual Studio. Microsoft instead recommended the vsFunnel extension to optimize memory by filtering low-priority projects, adding "we highly value your feedback." They cited a December MSDN post that had argued "smaller is faster," and that no performance benefits would be realized for users whose code and data already fit into a 32-bit address space, while most other issues could be addressed with better data design.
The day they broke that limit, some cheered. Others looked upon it with dread, knowing the hellspawn that would follow.
No, it's because they want to drive people to instead use cloud services so that they can get into control of all your data.
To Microsoft and Oracle the desktop operating system is a necessary evil and they want a transit into thin clients. But they don't want the users to understand that they do it, instead it's a free "upgrade".
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
This right here.
This is IE 6.0 all over again. Major products they push on everyone. Then let them rot in place.
VS2015 is very cool. It is also *VERY* flaky. I have had to reinstall it no less than 5 times now because 'something' breaks. Woe unto you if you have to bring up the repair screen. Plan on that bitch taking 3-4 hours to change 1 package.
They neglected C++ for so long on their train to .net (which is 64 bit hmmm). clang and gcc now regularly destroy them on compatibility and speed.
They are so hell bent on making platforms they forgot to make product. I remember standing in long ass lines to buy windows 98. Fast forward to today. Very few actually *want* windows 10. For me getting network backups back again was worth the upgrade.
Also they are making a rather extraordinary claim that x64 is slower than x32 with visual studio. They should do something like oh I dont know 'recompile it as 64 bit' and PROVE IT and show their work?! Perhaps oh I dont know ON A BLOG POST?! You couldnt find a few interns and a couple of seasoned guys to make it work? Out of a company that big? I call shenanigans.
MS there is a reason everyone is jumping to other platforms. Yours is just not up to date and you change your mind every 3-4 years on what platform you want to push. Then the platforms MS comes up with are pretty much 0% compat with the old ones. So you can not even re-use your code. You have to throw it all out and start over. MS this is why devs no longer want to work with your crap.
But there's no reason they couldn't handle that the way lots of us do. If you need to load 32 bit modules in a 64 bit program you just launch a 32 bit host process and reparent the UI onto the window handle of your main process.
That would be really useful anyway, because those controls are where there worst memory leaks in studio can be found. Putting them into external processes makes it easier to throw them out and free memory.
With a very few specific possible exceptions, x64 code is indisputably faster than x86. The reduction in register pressure buys you a speed increase of about 10% in my experience.
The code is somewhat larger, of course, but instruction caches have also grown in size since this was observed to be an issue.
Meanwhile, recompiling correctly-written C++ code to target x64 amounts to changing a couple of flags in the build script, so laziness is no real excuse.