I suggest you ...

Improve performance of Visual Studio builds and other uses better when working with solutions with several projects (ex. 40+)

When working with a large number of projects in a solution, builds and loading of the solution can become quite slow. We are currently working with around 40 projects and Visual Studio is starting to crawl and this is unfortunate since we are aiming at having possibly over 300 total projects part of the solution due to a modular application design but are afraid of doing so due to performance woes. Making Visual Studio better at handling large projects in terms of performance and also in terms of ease of navigating between projects and their contained files will greatly reduce a barrier to scaling large applications.

1,055 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…)
    jeffpiersonjeffpierson shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    Anonymous shared a merged idea: Distributed Builds  ·   · 

    18 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...
      • Arne KleinArne Klein commented  ·   ·  Flag as inappropriate

        Is there anything done in this area?

        It seems that performance is actually getting worse as of today.

        We are working on an MVC application with currently 30 projects and we updated the project to VS 2013 and MVC 5 this week. It seems like the performance decreased a lot since the update.

      • BrianBrian commented  ·   ·  Flag as inappropriate

        I think that the VS team should look at what the red-gate.com team did with .Net Demon. This only rebuilds projects and dependencies that changed after a save and definitely speeds things up under most conditions. It is also inexpensive. It could use some enhancements for some of the special things I do, but it is a good solution for 90%+ of most projects. (And I don't work for red-gate)

      • DaverDaver commented  ·   ·  Flag as inappropriate

        At work, our VS solutions are now fairly large. It seems to take forever for me to load a VS Solution. Can't we load all the files, let me open a file and edit, and then let VS do what it needs in the background?

        When I press F5, I really want the website to be running ASAP. If possible, I'd like to see it up instantly. I have lot of ideas I want to try when debugging and I forget them when I have to wait a long time.
        When you think about it, unless we are code generating with T4, the code is pretty much static. Only the code we are modifying should actually be changing. While I'm making modifications to code, perhaps Visual Studio can utilize those extra CPU cores to background compile C#, or index the contents of the HTML DOM, or preparse the javascript, etc. Or maybe the changes I made should be recompiled. Just my 3 cents.

      • Bilbo BagginsBilbo Baggins commented  ·   ·  Flag as inappropriate

        "40 projects" - .... :-D ... we currently have about 250-300 VC++ projects and a couple of C#/.NET

      • MaxMax commented  ·   ·  Flag as inappropriate

        There is no good way to handle multiple projects using Visual Studio right now. If you put them in one big solution then VS gets slow. If you put them to different solutions then you need a lot of memory: http://visualstudio.uservoice.com/forums/131389-visual-studio-performance/suggestions/2255208-decrease-the-memory-footprint . If you only load the solution you work on at the moment then you will be waiting a lot for VS to start up/shutdown because of http://visualstudio.uservoice.com/forums/131389-visual-studio-performance/suggestions/2255206-make-visual-studio-startup-and-shutdown-faster and http://visualstudio.uservoice.com/forums/131389-visual-studio-performance/suggestions/2197975-make-solutions-load-faster .

      • Patrick SmacchiaPatrick Smacchia commented  ·   ·  Flag as inappropriate

        While MS had always fostered a multiple VS projects environment, I found out that reducing the number of projects to a strict minimum is a good idea for several reasons, one being that VS environment dramatically slows down not because of the size of the code, but because the code base is partitioned in multiple projects.

        I wrote a white book on this topic: http://www.ndepend.com/Res%5CNDependWhiteBook_Assembly.pdf

      • Pavel MinaevPavel Minaev commented  ·   ·  Flag as inappropriate

        @Alexander
        >> It also doesn't use parallel build for C# projects

        Try it in VS11 Developer Preview; you might be pleasantly surprised :)

      • Anonymous commented  ·   ·  Flag as inappropriate

        We could pony up thousands of dollars for Incredibuild or Electric Cloud but this should just be built-in like distcc with XCode.

      • Andrew McGrathAndrew McGrath commented  ·   ·  Flag as inappropriate

        Would be good to know if a general solution to this problem is coming - we have developed our own solution as part of a larger web-based platform we have built on top of Visual Studio - I am happy to convert it into a free plug-in that runs inside Visual Studio, but that would take a week to do and test - so I would prefer to know if something is being done in this area.

      • Joe WhiteJoe White commented  ·   ·  Flag as inappropriate

        The Solution Navigator from Productivity Power Tools is unbearably slow when you have too many projects (we have over 100). Now it's replacing Solution Explorer, which sounds like really bad news.

      • PaulusPaulus commented  ·   ·  Flag as inappropriate

        I try to avoid working with so many projects (XAML & C#) under one solution. However, such setup has one major benefit: it helps me avoiding unwanted circular references between project items (C#classes/interfaces). When setting a project reference detects such circular reference, it is mostly a signal of some overlooked flawed design on my part.

      • Alexander BuryakAlexander Buryak commented  ·   ·  Flag as inappropriate

        It also doesn't use parallel build for C# projects, and that is really a pity - especially when you have more than 30-50 projects in one solution on 4-16cpu machine.

      • teydeteyde commented  ·   ·  Flag as inappropriate

        My knee-jerk reaction to suggestion like this used to be thinking that so many projects in a solution is an anti-pattern. While I still think that, the problem is no less real.

        These days, I work routinely with a 60+ projects solution, and the IO penalty is heavy. With build times over 3 minutes, one can forget about TDD. When the application startup is just as long, on which I only blame past design choices, everything is associated with pain.

        One of the less intelligent things VS do, is to copy all referenced dll for all projects blindly, and not check if that file is already copied.

      • Catalin AdlerCatalin Adler commented  ·   ·  Flag as inappropriate

        We have over 70 projects in our solution, one of which is a databse project with more than 2000 objects.

        Loading, building, rebuilding and everything that needs compiled sources (like refactor, find references, open some designer) is painfully slow.

      Feedback and Knowledge Base