(Continued from Part 1)

So, nothing like some hard figures to help sharpen the mind…

Test 1

This test was centred around project structure… that is, the number of csproj’s and the type of references each held to each other.

Our test machine was an i7 with 8 gigs of RAM and a 7200pm HDD, each run was held after a fresh reboot, no other programs running (save a terminal session). MsBuild was executed from within a small python script, and the timing information was output to the console. The measurements which follows aren’t particularly scientific, however I hope they serve as an indication of what is possible.

Original Structure (our baseline)

This was a solution file of approximately ~80 projects & 125k LOC. There was quite a number of projects with only a handful of .cs files, and every project file was set to CopyLocal = true for its non-mscorlib references. This basically amounted to a collective output of thousands of assemblies, with many copies of the same third-party DLL’s in each output directory (think, 100’s of copies of nhibernate.dll & nservicebus.dll). Our build times were:

10 builds in 15:18 mins @ 1:31 mins per build

Assembly/Weak references (CopyLocal = false)

That CopyLocal setting (or <private> node in the csproj XML) that I mentioned above was resulting in a huge amount of file I/O for each and every build. So, following Patrick Smacchia’s advice from the article I linked to in the first part of this series, I converted every reference (via a little tool I wrote) to CopyLocal = false, and ran another test run. An 81% improvement… not bad.

10 builds in 3:08 mins @ 0:18 mins per build

Single Project file

Watching all those MsBuild instances scroll up my terminal window (apart from being ridiculously hypnotic), I noticed something else. MsBuild shelling out to csc.exe takes a rather long time, maybe a second or two each and every time. However, once its running the compilation itself is very, very quick. So, with the help of ReSharper (CTRL + R + O is your friend), I merged all the code into a single project file. The results are impressive - almost 2 orders of magnitude improvement!

10 builds in 16 secs @ 1.6 secs per build

Ok, so now we are starting to see where the bottlenecks lie in our build process. Next, I’ll be looking at the impact of various drives (HDD, SSD and RAMDisks) on compilation times.