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.
With VS2015 Update 2 VS stopped crashing when exceeding memory limit a little over 2GB. Rather it started displaying "Low memory detected" message... I have 16GB of RAM. VS can access only little over 2GB because it is 32bit app. Please make it 64bit so we, with bigger projects can use all the goodies that VS have! Thx
When running on a 64 Bit machine, it can be extremly annoying that Visual Studio can only access ~4GB of RAM, which can cause issues with larger projects. Please create a 64 Bit version of Visual Studio!
This could prevent crashes and hangs in larger Visual Studio projects.
Get rid of thunking issues, dual DLLs, remoted debugging required, and 32-bit default project nonsense. Upgrade the package to native 64-bit.
In the modern 64-bit desktop computer world, 32-bit apps are woefully inadequate and archaic. Show a little innovation and keep up with tht times. Raw GUI performance is not everything these days, that is really lame excuse not to rebuild for 64-bit.
Most Microsoft server products that we develop against now run in 64 bits. However the VS IDE is still only available as a 32 bit version.
Integrating the IDE to these server products, eg automating development tasks when targeting SharePoint, BizTalk etc, is now often unfeasible because the object models or PowerShell commands that you need to invoke won't run in a 32 bits process.
By eliminatig the 32/64 bit boundary (Wow64) between the IDE and MS Server products integration on 64 bit systems will be much easier.
I have to load some huge projects that would benefit of using access to full available RAM
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
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.
I know it's cool to hate options in Microsoft-land these days, but what if you provided two binaries, one 32, one 64 bit? Users then could choose between increased performance or no crashes.
I have migrated my big projects to Bjam, without vs, it's very fast. VS becomes slower and slower since 6.0, it's time to select better tools.
Jon Miller commented
Steve B commented
This is a joke. Why does EVER OTHER PROGRAM IN EXISTENCE see performance benefits from moving to 64 bit, but Visual Studio would not? You guys are really drinking the Kool-Aid if you honestly believe the bull$hit you're shoveling.
I.e. "we screwed up the code so badly we don't want to spend time fixing it to be 64-bit ready but don't want to admit it"