Geeks With Blogs
Mark Pearl


Recently I looked into speeding up Visual Studio builds – I found the results interesting… I decided to do a few POC’s to see where the bottleneck is with large solutions in Visual Studio.

After some searching on the net I found various tweaks that one can do to ones machine to get better performance and a few mentions that VS2010 does not handle multiple project files very well – the number mentioned several times was 10 – if you have more than 10 projects in a solution you see a noticeable decrease in build time and responsiveness.

Here were my findings…

Solution with 100 projects each with a single class

I set up a solution with 100 class projects with a single class in each project and did a clean build on the solution. The average build time per project was 00:00.2 units, leaving me with a total build time of 00:16.0 units. Not terrible, but remember these projects are about as small as they can get – this is the best case with this scenario.

Solution with one project and 100 classes in a single namespace

The next step was to establish where the load was on the build, would I get similar results with a solution with one project with 100 classes? Again I set up a solution with one project with 100 classes (exact same content in the classes) – total build time 0:00.17 units, significantly faster.

Solution with one project and 100 classes in separate namespaces

Still not sure if possibly I would see a difference if I had multiple namespaces in one solution, I made another solution with one single project and a 100 different classes – each in their own unique namespace.. nada, still getting performance around 0:00.17 units, significantly faster than one solution with 100 projects with one class per project.

Graphically shown it tells its own story

Build Times


Keep as few projects as possible in a solution. It is nice to have projects as a physical separation of units of code, but if you plan on keeping them in the same solution you are opening yourself up to build time pain.

I would suggest rather using as few projects as possible in a solution – approach A would be if you can separate the solution into multiple solutions (keeping your project count as low as possible). If you don’t like the multiple solution idea you can always take approach B and have a one solution strategy with multiple namespaces within the single solution to isolate things and show the boundary line of what goes where.

With approach B it will require some discipline by and team consensus with your developers, but I am sure they would prefer this than losing hours of their day building a solution. And that’s my take on things – by all means do the hardware tweaks of setting up ram drives etc. – but fundamentally rather avoid the problem totally – If I have missed something obvious or you know of an awesome way to get past this problem, please leave a comment!

If you would like to do your own investigation you can download the test solutions from here and run your own scenarios.

Posted on Thursday, May 24, 2012 6:10 PM Architecture | Back to top

Comments on this post: VS2010 Large Solution Bottle Neck

# re: VS2010 Large Solution Bottle Neck
Requesting Gravatar...
Good info, it would even be cooler to see these metrics at run-time.
Left by Travis on May 24, 2012 6:36 PM

# re: VS2010 Large Solution Bottle Neck
Requesting Gravatar...
Very true but even more often ignored. Especially if you have many architects trying to bring governance into a project by structuring the assemblies according to the component layering. Where component structure most often simply reflects the team structure ....
Left by Alois Kraus on May 25, 2012 12:11 AM

# re: VS2010 Large Solution Bottle Neck
Requesting Gravatar...
I had this exact same problem at my last two jobs. Unfortunately at the second last job, I didn't do anything (various reasons, boss didn't like it, he didn't trust, nor want to break things out, and I didn't want to rock the boat). But in my last job, I created a couple of smaller solutions with JUST the projects required for that specific task (one for the web and two for two thick clients).

The thing was, since I was only adding three solution files and not touching the BIG one, our regular build to produce our releases could still continue! That was the magic, I couild break things out, everyone could dive in, do what they had to, F6, F5, bada bing, bada boom, all the while, not impacting the release builds!

So for people looking at this saying it won't work for your Release Deliverables, yes, it will, just add another solution, not replace it.
Left by PHenry on May 25, 2012 12:16 AM

# re: VS2010 Large Solution Bottle Neck
Requesting Gravatar...
For all versions for VS, one of the best ways to improve performance is get faster disk, if you can a SSD is perfect:

For VS "11" there is some very important changes to performance, and in particular build performance:
Left by Robert MacLean on May 25, 2012 10:26 AM

# re: VS2010 Large Solution Bottle Neck
Requesting Gravatar...
LOL on graph - it tells a good story. Thanks for post.
Left by Ken H on May 25, 2012 9:29 PM

# re: VS2010 Large Solution Bottle Neck
Requesting Gravatar...
My rule of thumb is that you only split to a separate project if you are actually going to be deploying the items separately. Unfortunately in an enterprise scenario this can still result in you having a lot of projects.

To add to PHenry's comment - you don't actually even need to include your 'personal' solution files in version control, you can just have them on your own local machine and you don't then affect anyone else at all.
Left by Kevin Trethewey on May 28, 2012 4:39 PM

Your comment:
 (will show your gravatar)

Copyright © MarkPearl | Powered by: