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.
jeffpierson
shared this idea
14 comments
-
Brian
commented
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)
-
Daver
commented
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 Baggins
commented
"40 projects" - .... :-D ... we currently have about 250-300 VC++ projects and a couple of C#/.NET
-
Max
commented
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 Smacchia
commented
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 Minaev
commented
@Alexander
>> It also doesn't use parallel build for C# projectsTry it in VS11 Developer Preview; you might be pleasantly surprised :)
-
Anonymous
commented
We could pony up thousands of dollars for Incredibuild or Electric Cloud but this should just be built-in like distcc with XCode.
-
Ofek Shilon
commented
Just use incredibuild.
-
Andrew McGrath
commented
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 White
commented
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.
-
Paulus
commented
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 Buryak
commented
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.
-
teyde
commented
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 Adler
commented
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.
