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.
32 bits ought to be enough for anyone.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
It's not about doing the work, it's the outsourced Indian team doesn't know how to do the work.
It's not about doing the work, it's the outsourced Indian team doesn't know how to do the work.
I am pretty sure this is the actual reason, not just cynicism. MS has fired or encouraged significant attrition amongst it's can-do types, focusing those few who remain and who know how to do things into certain areas. The rest...they've backfilled with H1B or outright offshoring. Any other company would have collapsed by now, but monopolies are a powerful thing.
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.
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.
I submitted the story, so yea.. I read the links. I added my $0.02 to the linked issue years ago. One does follow the other. They're obviously willing to spend some money in some areas of the product, but unwilling in this case. Those oddles of plugins are what makes Visual Studio desirable. As for drowning kittens, there's a lot of that going around. So many 32-bit kittens, never going to grow up to be 64-bit.
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.
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've also been using Vim since the early 00s.
I'm stuck, and still didn't figure out how to quit the editor.
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 submitted the story, so yea.. I read the links.
Slashdot has really gone downhill as of late. First readers are starting to RTFA, now submitters are RTFAing before they submit. Pretty soon we'll have well informed discourse and at that point why would anyone come to Slashdot to read the comments anymore.
They should do something like oh I dont know 'recompile it as 64 bit' and PROVE IT and show their work?!
I don't have to see the compilation to understand that it is going to be slower: I can read processor spec sheets. All modern processors can do 32 bit pointer arithmetic in a single instruction. This is critical because pointer math is highly linear in nature and *will cause pipeline stalls*. 64 bit arithmetic by contrast is typically several cycles long, and will commonly stall the pipeline. The performance hit I have commonly heard is 10%, and seems to come from some amount of informal testing.
Take a look at this for an idea of some of the testing that gets done on these kinds of things.
I wish I had a good sig, but all the good ones are copyrighted
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.