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.
We don't want to do the work.
32 bits ought to be enough for anyone.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
The day they broke that limit, some cheered. Others looked upon it with dread, knowing the hellspawn that would follow.
The real problem is that the fancy built-in designers, such as the WPF designer, only work with 32-bit components in 32-bit Visual Studio. When someone writes a component that is 64-bit, because it references a DLL that in-turn references, say, a 64-bit Oracle driver, which is part of code that we don't have control over. Now the designer won't load and shows a cryptic error message.
I have a quad core 3.5Ghz with 32GB of RAM, VS2015 installed on an SSD. It takes over 15 seconds to get to a working state. After the last update (2), then the Update patch, it now pops up some idiotic error about scc something-or-other every time it starts, and every time I open a project. An update for this POS software takes at least 15 minutes -- with far and away most of the time spent sitting at 99% complete with the status message: "Visual Studio is configuring itself -- this might take a while."
Yeah no shit it might take a while.
In summary Visual Studio has become one of the worst programs I use. It is horrifically bad in all aspects: Hard to use, impossible to navigate, useless documentation.
When I wander over to the C++ forums on reddit I frequently see their runtime library/compiler guy -- I think his name is STL, sheepishly saying what an antiquated POS their C++ compiler is. That doesn't give me warm fuzzy feelings either.
It's all just more nails in the coffin as far as I'm concerned. I rarely develop for Windows anymore and when I have to it's because I'm forced to. The entire Windows platform is a complete disaster from a developer's point of view. All the years of MSDN trying to sell whatever the current darling language, what's-old-is-new-again (C++ is back, did you notice?), terrible, TERRIBLE API design, and just general CRUFT (did I mention that COM is back too..?) have finally caught up to them.
is and has always been a disgusting kludge on top of the 32-bit (that they finally managed to get in decent shape). Faced with the necessity to build something just as ugly for another product, I'm not sure I would have reacted differently than they did.
Oh, and the bit about valuing the feedback is priceless, of course.
I can assure you, the best way to get rid of dragons is to have one of your own.
Damn right, any project this big should be done with professional tools!
Glad MS finally admits it.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Microsoft develops software the same way the British Army fought the Somme Offensive. They use massive amounts of cheap programmers, and just pound away until they have something to release. The code quality is so poor that they often just throw it way and do a complete rewrite for the next version. You may think that supporting 64 bit would mean just changing a few header files, tweaking some compiler flags, and typing "make world", but it would not be that simple. The code is likely riddled throughout with obscure 32 bit dependencies, and would require a huge and expensive effort to fix.
The big problem is debugging.
We've got a 64-bit app which VS will happily build and the app runs fine. But if we want to debug it live VS chokes, falls over and dies, out of memory once the app uses more than 3 GB.
It's legit using > 4GB because it's heavy image processing of large color images at high dpi and the machines are specced for it. Obviously, we could page stuff in and out of memory ourselves, but that rather defeats the purpose of 64-bit OS and would slow everything down (speed is paramount here, burning memory to get it was a primary design decision) - and the program runs fine when not debugging in VS.
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.
"also, fuck you, developers."
Shouldn't that be:
"also, fuck you, developers, developers, developers" ?
I'd give my right arm to be ambidextrous.
I did a couple of 64-bit ports in the past and that's pretty much what it took. The first application was about 50000 lines of code that I had worked on for about a year, i.e., I didn't write it, but I fixed it and refactored it. That conversion took about 2 days, and most of that was making small fixes because the header files were reorganized between gcc 3 and gcc 4.
The second time I did it was for a code base of about 2 million lines of code that I did not "own" in the same way. That took about three weeks, plus about another week from another developer. This was not code that had been developed in a well-disciplined way, but it worked, and the conversion ended up being very successful and took a lot less time than management had expected.
I worked at MS in early 00s. We didn't use VS to write code. We used a stripped down version of VS or even WinDbg to debug. Nowadays I use Vim and YouCompleteMe (on Linux) and it just works. Zero dollars, easy to set up.
I've been a developer for 15 years and I can say Visual Studio environment is way better than anything available on Linux. The code dependencies can be resolved in 64 bit but Microsoft is a business and there's an opportunity cost associated with doing that rather than something else more people actually need.
I bet their compiler catches most of the bad shit that only works on 32-bit builds... But they have so many warnings they can't see this.
The code quality is so poor that they often just throw it way and do a complete rewrite for the next version.
Based on what? For the most part when MS projects have either had source code leaked or made open source the analysis of the code has shown some pretty fine programming. Re-writes seem to be based on strategic decisions and also decisions to not end up with endless layers upon layers of cruft (something that also supports code quality in a positive way).
I'm sure Visual Studio works quite well for you. But, to counter one anecdote with another, I found Visual Studio to be lackluster and irritating in a thousand little ways, and its marginally-better code completion isn't enough to make me prefer it over either Eclipse or QT Creator.
As for a 64-bit Visual Studio, my guess is that the code problems of porting to 64-bit are dwarfed by the bureaucratic maze involved in releasing a new edition of a product.
It would probably suck worse, because the memory leaks and plug-in bloat would be only bound by physical memory, rather than the enforced 32-bit memory space.
If Microsoft is telling people that they should just write better code in order to stay inside of a 32-bit boundary, they should start practicing what they preach and lead by example.
Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.