I suggest you ...

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.

3,124 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Catalin AdlerCatalin Adler shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    JacobJacob shared a merged idea: Make Visual Studio 64 bit application!  ·   · 
    Anonymous shared a merged idea: Create a 64 Bit version of Visual Studio Community  ·   · 
    SequiturianSequiturian shared a merged idea: Upgrade Visual Studio to native x86_64-bit code.  ·   · 
    VincentHVincentH shared a merged idea: Create a 64 bit version of the IDE for better integrated development against 64 bit server products  ·   · 
    amselemamselem shared a merged idea: Create x64 version of Visual Studio  ·   · 

    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

    62 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • DukeDuke commented  ·   ·  Flag as inappropriate

        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.

      • MilanMilan commented  ·   ·  Flag as inappropriate

        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

      • Anonymous commented  ·   ·  Flag as inappropriate

        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.

      • Anonymous commented  ·   ·  Flag as inappropriate

        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.

      • Anonymous commented  ·   ·  Flag as inappropriate

        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.

      • spinlockspinlock commented  ·   ·  Flag as inappropriate

        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 MillerJon Miller commented  ·   ·  Flag as inappropriate

        Maybe Microsoft expects everyone to switch to Visual Studio Code which was written in TypeScript. I thought at least part of Visual Studio was developed in .NET. Why not make it all .NET? Porting it to .NET Core wouldn't be a bad idea either once that solidifies. If the problem is that there are 32 bit extensions that won't work, then, at least create a 64 bit version without support for that. Maybe there are developers that don't need the extensions. Maybe if we just all convert to using JavaScript we won't need 64 bit!

      • Steve BSteve B commented  ·   ·  Flag as inappropriate

        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.

      • Anonymous commented  ·   ·  Flag as inappropriate

        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"

      • Daniel PamichDaniel Pamich commented  ·   ·  Flag as inappropriate

        Please listen to you customers. Visual Studio just doesn't work as a 32bit software, I have it crash 3-4 times daily due to it running out of memory. Small projects work fine, large ones crash regularly.

        If I have to unload projects via VS Funnel, I might as well go back to using a text editor. As all the features I now need in an IDE don't work. In fact the pure existent of VS Funnel proves there is a major issue with 32bit VS!! If VS worked as it should there wouldn't need to be these desperate work arounds!!!!

        SQL Server has got massively faster since it moved to 64bit, maybe their team can give your team some tips on high performance data structures and 64bit code.

        I don't care if VS is slightly slower when it moves to 64bit, I just want an IDE that is stable and works with large solutions.

        Please reconsider this decision, so your customers can have a working IDE.

      • Andreas ErbenAndreas Erben commented  ·   ·  Flag as inappropriate

        Is this a joke? This is 2016.
        Let me add - I do not think that Microsoft should be in the business of telling people to use hacks like swapping out projects out of memory.
        Pretty much all integrated environments there are that work with large amounts of assets have a 64 bit version. An increasing amount of software in the industry is only produced in a 64 bit version. For Microsoft server products this is pretty much the case universally. And frankly - today, the difference between the footprint of a desktop or a server system are both beyond the 32bit threshold anyways, even a standard notebook configuration nowadays is 8GB. Only niche systems are running on less than 64bit.
        If there are benefits of having parts of it running in 32 bit or have a 32 bit option - then encapsulate those, instead of going the other way to be restricted for good by a 32 bit limit.

        The response feels, sorry to say, like an elaborate cop-out.

        On one end you talk about performance issues (which I am sure there are ways to address with a specific mode for it, so give people a 32bit mode or subsystem if they want to), on the other hand you have absolute limitations that cannot be overcome in the 32bit world.

        I am aware that VS is a behemoth - and there are many aspects to consider, still, back to the original point - 2016 to look at an application and even remotely implying that it is *better* as a 32 bit application when even smart phones switch to 64 bit - feels - wrong.

      • James JohnstonJames Johnston commented  ·   ·  Flag as inappropriate

        "we suggest you to leverage the VSFunnel extension ... by unloading projects not being used in a smart way"

        Why does this remind me of MS-DOS programming in the 1980s? Maybe some of them still work for VS Team? https://en.wikipedia.org/wiki/Overlay_(programming) --- "An overlay manager ... loads the required overlay from external memory into its destination region when it is needed. Often linkers provide support for overlays."

        I thought we got past this in the PC world with Windows NT & virtual memory in 1993. Operating systems have this nifty feature called "virtual memory" and "swap space" so that users don't need to be concerned with manually loading & unloading data to fit into limited "memory." You just need to increase the address space to 64 bits to continue to grow.

        Please don't force the bad old days of MS-DOS-style overlay programming on us!

      • Bruce ShankleBruce Shankle commented  ·   ·  Flag as inappropriate

        Could someone at Microsoft forward this to Don Box? I'm curious if he agrees with this. Sounds like an absurd cop-out to me. There are many benefits to a 64-bit address space. Why would you cite performance degradation 'possibilities' as a reason not to do something that prevents the product from being completely unusable for large-scale things?

        At the very least fire up razzle and do a 64-bit build yourself and share some 'real' numbers with us. We're not stupid.

      • WarcusWarcus commented  ·   ·  Flag as inappropriate

        Absurd! Heresy! Blasphemy!
        I had count to 10 before commenting on this post, I was so angry especially after reading ricom’s so technically and realistically weak argumentation on why a studio is better than a mansion.
        Every dev in my company has 64 GB RAM in their desktops, that costs nothing compared to their paychecks. And you make them wait on an hour glass while you do swap? That is not even to mention the context switch and frustration. I want to keep everything in memory just because it is there, it is empty, it is cheap and makes me more productive. Stop constraining me! Let me fly!

      • meme commented  ·   ·  Flag as inappropriate

        You are not listening to your customers. They are trying to tell you something. You are then spinning it around back in their faces as if they are doing something wrong. It is good for you to come up with a suggested work around. However, that will not fly for long. They will want a solution to the problems they are TELLING you. Listen to them or they will just move on to another platform that does support them.

        This may be difficult to hear but your customers are telling you what to prioritize. So you have a few choices here. You optimize VS to work much better in 2 gig and with resharper not blow away all the memory. You find out how to make the profiler not blow away a bunch of memory. You find out how to make that all work in 2 gig nicely. Your customers *CAN'T* They do not have access to the source code like you do. They are relying on *you* to fix the perf and memory issues not give them flimsy excuses. It is why they buy those nice 3k MSDN licenses. Or you tell them 'oh well not that big of a deal'. They will just move onto other platforms that can do what they need.

      • NunoNuno commented  ·   ·  Flag as inappropriate

        There's a scenario that right now that VS can't do: profile applications that run for over one hour. The profiler in VS crashes because it runs out of memory.

      • Bill HoagBill Hoag commented  ·   ·  Flag as inappropriate

        I agree with the other commenters that 32-bit architecture is too constraining for Visual Studio. As an everyday user of VS (on a large C++/C# solution using Resharper C# (VS usually tips over with Resharper C++)) who has to endure it's sluggishness and restarts due to a memory straight-jacket. The features that want to make VS great (Intellisense and all of the nifty stuff when right-clicking on code) need to keep LOTS of reference data in RAM - too much for a 32-bit architecture. Please reconsider your decision.

      • Stian FagerengStian Fagereng commented  ·   ·  Flag as inappropriate

        A well composed excuse for focusing on the hipsters doing Web.
        As a old grumpy programmer working on the same solution for the last 10 years I feel neglected.

        I put my trust into the marked laws, and expect a good alternative to VS popping up soon.

        \\Stian.

      • Dominik GschreiDominik Gschrei commented  ·   ·  Flag as inappropriate

        You must be joking. So your solution to "Visual Studio will constantly run out of memory" is that we should effectively stop using VS as an IDE.
        VSFunnel is great if you don't care about basic IDE functionality like automatic refactoring/renaming because of course those will not happen in the projects you didn't load.

        Never mind that running all unit tests of the solution becomes impossible when half the solution isn't even loaded. (Which is a requirement in our team before every checkin(and a sensible one at that))

        Frankly from a simple customer's standpoint I feel insulted by this reply. For the thousands of dollars Microsoft takes for VS Enterprise I expect the thing to cover our use cases and not us tailoring our use cases to your inadequate product.

        And our use case is definitely not atypical. It's a solution a 10 man team has been working on for the past 2 years, with ~100k LoC of product code and ~10k unit tests and yet every day VS 2015 tells me that features have been turned off because it ran out of memory.

        Just install Resharper on your test machines and watch your memory budget evaporate. And not using Resharper is not an option here because our company requires all developers to have it installed. (And frankly I wouldn't want to go without it anyway)

        You could of course stop the futile endeavour to write insanely clever 32bit code to somehow escape the hard 4GB limit and start writing insanely clever 64bit code to avoid the much more forgiving performance issues.

        If 64bit VS becomes too slow we CAN buy faster computers. If 32bit VS runs out of memory on a 32GB equipped machine (medical imaging software eats RAM like candy) with only ~16GB in use we can do NOTHING. Just saying

      ← Previous 1 3 4

      Feedback and Knowledge Base