posts - 293 , comments - 413 , trackbacks - 0

My Links

News

View Steve Michelotti's profile on LinkedIn

Twitter












Tag Cloud

Archives

Post Categories

My Online Presence

VS2010 Large Solution Bottle Neck

 

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

Conclusion

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.

Print | posted on Thursday, May 24, 2012 6:10 PM | Filed Under [ Architecture ]

Feedback

Gravatar

# re: VS2010 Large Solution Bottle Neck

Good info, it would even be cooler to see these metrics at run-time.
5/24/2012 6:36 PM | Travis
Gravatar

# re: VS2010 Large Solution Bottle Neck

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 ....
5/25/2012 12:11 AM | Alois Kraus
Gravatar

# re: VS2010 Large Solution Bottle Neck

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.
5/25/2012 12:16 AM | PHenry
Gravatar

# re: VS2010 Large Solution Bottle Neck

For all versions for VS, one of the best ways to improve performance is get faster disk, if you can a SSD is perfect: http://weblogs.asp.net/scottgu/archive/2007/11/01/tip-trick-hard-drive-speed-and-visual-studio-performance.aspx

For VS "11" there is some very important changes to performance, and in particular build performance: http://blogs.msdn.com/b/visualstudio/archive/2012/03/19/visual-studio-11-beta-performance-part-3.aspx
5/25/2012 10:26 AM | Robert MacLean
Gravatar

# re: VS2010 Large Solution Bottle Neck

LOL on graph - it tells a good story. Thanks for post.
5/25/2012 9:29 PM | Ken H
Gravatar

# re: VS2010 Large Solution Bottle Neck

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.
5/28/2012 4:39 PM | Kevin Trethewey
Post A Comment
Title:
Name:
Email:
Comment:
Verification:
 
 

Powered by: