(continued from Part 2)

Test 2

This was centred around the choice of disk drive. We’re building a slightly different project from before, but similar size (about 100k LOC) and structure (about 55 projects). This main difference this time was that MsBuild was being executed with the following property:

OutDir=c:\A\Single\Output\Directory

So we are cutting out a LOT of I/O. Every assembly, including the lib ones, are being copied only once per run. So this negates a lot of the purported benefits of SSD and RAM drives, but IMO it ends up being much more indicative of the kind of improvements you can get from good architecture (refer to Test 1). Finally, we are also cleaning each bin & obj directories before each pass:

HDD - 5 builds in 3:00 mins @ 36 seconds each

SSD - 5 builds in 2:37 mins @ 31 seconds each (~15% faster)

RAM* - 5 builds in 2:20 mins @ 28 seconds each (~23% faster)

I also ran another RAM disk run using the original project structure in Test 1

10 builds in 03:06 @ 00:18 per build (~80% faster than the original 91 seconds)

* The RAM Disk used can be found here: http://www.ltr-data.se/opencode.html/#ImDisk

Conclusions

So what can we infer from these results? Well, quite a lot really - but as always they come with caveats.

1. I/O is a killer. Getting rid of all those copy local references took nearly 90% off the build time.

2. Csc.exe is fast. Damn fast. Spinning up all those Win32 subprocesses costs a lot of time, and when you only have to do it once, the compile times drop to near 0.

3. Faster drives help. But they only Band-Aid over the symptoms, you’ll get much better results by addressing the root cause.

Now obviously I’m not suggesting that you go and refactor your entire codebase into a single project file. There are lots of things to consider when structuring .NET solutions; the make-up of your deployable artefacts, separating test & production code, vertical & horizontal partitioning of functionality, “code re-use” (although the alleged benefits of this is a topic for another day) etc etc. However, its worth keeping in mind, especially early in the project, the potential consequences of design choices. 

Next time, I’ll be looking at the impact that CI tools can have on the speed of your build process.

PS. I discovered another little gem today. Sick of all those XML IntelliSense files clogging up your output folders? Try this little nugget, and shave 40% off your artefact sizes:

MsBuild.exe YourBuild.file /p:GenerateDocumentation=false;AllowedReferenceRelatedFileExtensions=none