Make VS scalable by switching to 64 bit
No matter how fast and efficient VS will be, we will eventually reach some limit.
I've reached the memory limit since VS 2003 -- around 1.3gb memory usage VS started to give out of memory exceptions. That was using 20-30 projects.
Nowadays we have more than 70 projects in the solution and VS 2010 doesn't reach the x86 memory limit (on a 64 bit windows). Eventually we'll reach the number of projects that will be the tipping point for VS.
Using a 64 bit build of VS will enable us to just buy memory and still work with that solution. 16gb machines are not that expensive today.
Many thanks to those of you to who provided the initial suggestion and all the related comments. We wanted to take a moment to provide further context to this issue and the context that informed our decision to close this.
Firstly, we recognize the spirit that is largely driving the request to move the Visual Studio IDE to be a 64-bit application: in particular, the ability to work with the largest solutions without performance constraints. We’ve made a goal for the division of driving performance improvements across the product, starting with Visual Studio 2015 Update 3, where we will be shipping many Roslyn performance improvements that will particularly reduce memory consumption with large projects.
As we’ve observed telemetry from Visual Studio usage from developers who have opted-in to share feedback with us, we’ve identified a number of other areas where we can improve performance. Some of examples of areas we’re working on in response to such data include:
• Performance improvements to the C# background code analysis engine that collects errors and warnings,
• Performance improvements to the C# GoTo Implementation and Find All References,
• Enhanced code analyzer diagnostic v2 engine,
• Better discoverability of UI to disable full solution analysis,
• Better messaging to users about the circuit breaker that system uses to automatically turn off compute intensive operations like full solution analysis when Visual Studio is under stress.
Another feature we’re adding to Visual Studio “15” that will enable it to support the very largest codebases is Open Folder (https://blogs.msdn.microsoft.com/visualstudio/2016/04/12/open-any-folder-with-visual-studio-15-preview), which enables any folder to be opened without first creating a solution or project. We’re using this feature internally as part of the development of Visual Studio with great results, and you can now check it out in the latest preview builds (https://www.visualstudio.com/downloads/visual-studio-next-downloads-vs).
Lastly, the work we are doing to create a lightweight installer will help reduce the number of components installed by default, which will also improve performance: https://blogs.msdn.microsoft.com/visualstudio/2016/04/01/faster-leaner-visual-studio-installer.
So why not just move Visual Studio to be a 64-bit application? While we’ve seriously considered this porting effort, at this time we don’t believe the returns merit the investment and resultant complexity. We’d still need to ship a 32-bit version of the product for various use cases, so adding a 64-bit version of the product would double the size of our test matrix. In addition, there is an ecosystem of thousands of extensions for Visual Studio (https://visualstudiogallery.msdn.microsoft.com) which would need to also port to 64-bit. Lastly, moving to 64-bit isn’t a panacea – as others have noted (https://blogs.msdn.microsoft.com/ricom/2016/01/11/a-little-64-bit-follow-up/), unless the work doesn’t fit into a 32-bit address space, moving to 64-bit can actually degrade performance.
So instead of a large porting effort to move the entirety of the IDE to 64-bit, we are instead working to target components that are resource-constrained today and move them out-of-process, which also offers other engineering benefits including better code sharing and more agile development; and we will continue to monitor overall system impact, not just the IDE impact.
In light of the above, we are closing this item for now since we are not moving the IDE to 64-bit in the next product release. Naturally, we will continue to consider this for future versions, but right now we don’t believe the scales tip in favor of this work. Of course, we remain heavily invested in 64-bit for runtimes, compilation, and profiling.
One last word about performance: when you have specific issues, it’s now really easy to use the feedback tools right inside Visual Studio to send us performance traces that can help us identify any potential issues. See instructions on how to do this here: https://msdn.microsoft.com/en-us/library/mt280277.aspx.
As ever, thank you for your feedback – keep it coming. We care about building the best and most productive development environment regardless of your target platform or development system.
Best wishes, Visual Studio Team
Robert McMillan commented
We are nearing a limit where we will no longer be able to debug our application in Visual Studio without manually filtering out some symbols. We are already to the point where we can't use the profiling tools without running out of memory. To add insult to injury, the symbol exclusions are ignored by the sampling profiler, so you can't even work around the problem! Either do some work to greatly reduce the amount of memory used by symbols or port the IDE to 64 bit. The market will eventually demand a proper 64 bit IDE, the only question will be if Microsoft makes it.
Translation: "Our code dates waaaay back, so we use bad pointer arithmetic and we can't seem to bog that down, any time soon. Sorry. But hey! We're listening to our customers"
Welcome to 2017 Visual Studio!
Various plugins and features e.g. performance profiling tools run out of memory in a 32 bit address space when used within professionally developed applications. A bit amateurish if you can't make a 32 bit app, really.
A needy user commented
How to vote for the renewal of this request?
Could not find any such new request.
Please vote on renewed variant of this request. - search for (Please, make a 64bit version of VS IDE). Pushing select components out of process isn't the solution. I spend a lot of time nowadays killing off the disoriented and confused offspring of vs - like xdesproc and Msbuild child processes.
What a ridiculously terrible decision. Visual Studio 15 on large projects is a complete mess. It crashes multiple times a day and is a buggy, unstable, piece of junk even on the latest updates.
It desperately needs more addressable memory. Not hacks to limit the size of the loaded solution (which by the way, don't prevent the crashes). This is a pathetic cop-out.
FIX THE PROBLEM Microsoft. "Doesn't merit the investment"? Maybe the next time I talk to our CTO, I should tell him that Microsoft technologies "don't merit the investment" because when they are faced with tough problems, instead of fixing things, they just pass the buck.
I have to restart VS a few times a day because of gradual leaks (aka. "rooted references", "robust memory caching", or whatever other term is used for going from a 500 MB working set to a 2 GB one) . True 64 bit isn't going to solve all our problems but it may give us the ability to run a bit longer without a restart. Heck, other IDE's like Eclipse have supported a 64 bit version a long time ago. Microsoft can surely do as well as that. Please reconsider!
Well, I would say they can at least give us 64bit version which is not backward compatible. To whom who want start new life. I am not able run in 32bit version of studio 64bit components in designer.
Bart Sipes commented
"at this time we don’t believe the returns merit the investment and resultant complexity"
Guys, please take a look at this recent blog post about the work that you (MS devs) are trying do to deal with Out of Memory errors and how the author of the blog post mentioned in the comments that "I am concerned about the performance loss from IPC vs internal calls however." https://blogs.msdn.microsoft.com/visualstudio/2016/10/12/reduced-out-of-memory-crashes-in-visual-studio-15/
Please just convert VS to 64-bit and just stop shipping the 32-bit version.
Phil Barila commented
While I can understand your reluctance to take this on, I think you've got it wrong. Moving different things out of process only goes so far, and delay loading (and eager unloading) eventually gets you to the point of re-implementing virtual memory paging.
Unless you've been ridiculously silly in your internal coding practices, by now you should be mostly 64-bit clean, anyway, and it should be a matter of running all your regression tests.
Well, if it's not addressed by Microsoft then it will be addressed by JetBrains via Project Rider.
Sergey Semushin commented
I think that extensions like Resharper would really welcome change to 64-bit and will recommend it to their customers because currently it's nearly impossible to work with large projects using Resharper. I believe that Microsoft needs to reconsider their treatment of this proposal.
Microsoft, we, your paying customers, need a 64-bit IDE in the next release.
The IDE performs badly, crashes, hangs and generally misbehaves with our large, business critical software.
Your customers have requested this, please keep them happy and don't fob them off with workarounds.
FYI, we have several thousand VS installations here. That's a lot of cash for an under-performing IDE.
James Hood commented
64th comment! Woohoo!
Look guys, we're fine with you dropping 32-bit devenv support. Just think of it as dropping VB6. Sure, you'll get UserVoice suggestions to "bring back 32-bit devenv" for eternity, but the majority of your developers will be happy with the change.
I agree that 64-bit isn't a panacea for performance, in fact I just perused an article in the April 1993 issue of Microsoft Systems Journal that was discussing the introduction of 32-bit Win32s (on Windows 3.1) and it made many of the same points. Obviously a memory leak or a poorly-selected algorithm or architecture is going to be a problem whether it is in-proc or not. Moving items out of proc is really just a stop-gap measure for 32-bit memory space exhaustion and adds some performance overhead and data duplication.
VS itself seems to make due with the 32 bit memory budget just fine. But Resharper is a memory hog.
Resharper is so valuable that all serious developers have it installed.
Resharper *should* move its data out of process but apparently this is very hard to do (as they have not done so for many years).
I believe that most developers do not depend on native code addins. Addins breaking is not a concern. Most managed extensions should be portable to 64 very easily. Since the 64 bit VS version will find *great* and immediate adoption all relevant plugins will be ported very quickly.
Also, I would sacrifice any plugin and any feature at all for a 64 bit version.
As someone who often runs up against memory limits in VS, despite having a 64GB workstation, this flippant and extremely belated response to a very reasonable, much needed, and long-overdue feature infuriates me.
MS's arguments against moving to 64-bit are straight from 2009.
Reduced performance from a move to 64-bit? Ok, just offset that with these other improvements you say you are making, done and done.
Doubling product matrix? Just make 2015 the last 32-bit version. Anyone who has a use case for 32-bit can just stick with 2015 or earlier. Just like anyone with a use case for 16-bit can stick with VB4, lol.
Many active extension authors would jump at the chance to port their extensions to 64-bit, because they are feeling the same pain as the rest of us. How many times in the past has MS rebased the extension ecosystem? More than once by my recollection.
I think y'all are so used to the rancid, 32-bit flavor of your dog food that you don't notice like the rest of us how disgusting it tastes.
Oh, and closing this legitimate request and killing voting on it was inappropriate.
Kasper Østergaard commented
Nice way to ignore Rico Mariani's own semi-rebuttal to his own article: https://blogs.msdn.microsoft.com/ricom/2016/01/04/64-bit-visual-studio-the-pro-64-argument/
This is a ******** decision and argument.
On of the bigest .Net project at hungary cant use some sollution wide code analytic and diagnostic tool of Visual Studio because not only the whole sollution with its 15 project but some single sollution is even bigger than the tools can handle and the studio just says low memory detected and the tool is disabled for this sollution.
The problem is that while the development machine contains 16 Gigs of ram and a 64bit windows 10 the Studio only eat ~3,5-4Gigs which maks the system to have more than 6-8 gigs of ram free while the IDE says low memory detected.
Somewhere under a million lines of code the IDE just die :S
The fact that it took you 5 ******* years to respond, shows how little respect you have for your customers.
Apple isn't abusive, and I welcome every last Microshit user to switch. you'll be happy you did.
and this reluctance to fix your ******* bugs is why OS X and linux are gaining ground quarter after quarter, for a decade at this point.
I can't wait for this terribly managed company to bite the dust, and I can't ******* wait to laugh in Gates face at how he thought he was brilliant for hiring lazy people, and they're his ******* undoing.
Good ******* riddance.