Reducing build time when using Code Analysis

by toni 6. August 2011 20:23

In QuakeCon 2011 keynote John Carmack talks about static code analysis (skip to 1h 2min if you want to listen the quote):

I've really gotten behind the static code analysis. The Microsoft analysis tools are always on and warnings as errors. Can't build the game if it complains about anything. And even when it's wrong - even when you have something you can prove "it's guaranteed OK" - that's actually a good time to step back and say "if you had to explain that to me, maybe you should have to change the way it's working." If the analyzer can't figure it out, other programmers probably won't immediately figure it out, and that will cause problems too...

When developing I’m usually using the static Code Analysis feature on Visual Studio. It is really great tool for finding possible bugs (i.e. calling virtual methods inside constructor) which are hard to spot. There is one problem about code analysis – it is too slow on C# projects. Even if you have good machine, SSD etc. the static code analysis takes a lot of time. When you are constantly building that time adds up. Seems that I’m not the only one who has noticed this since someone filed a bug about it. In order to have faster build times you have to disable the following rules:

CA1062 Validate arguments of public methods
CA1303 Do not pass literals as localized parameters
CA2204 Literals should be spelled correctly
CA2000 Dispose objects before losing scope
CA2100 Review SQL queries for security vulnerabilities
CA2202 Do not dispose objects multiple times
CA2215 Dispose methods should call base class dispose
CA2241 Provide correct arguments to formatting methods

I decided to see how much of a difference would it make and below are the results (times are expressed as seconds and fractions of second) of full rebuild:


The results are pretty clear. Disabling just few rules decreased the build time by almost 30%. If your build times are long and you are using code analysis see how much of a difference it makes to disable those rules. I’m interested to hear about your success especially on larger projects where full rebuild might take over 10 minutes on a modern machine.

Comments (2) -

Martin Anderson
Martin Anderson United Kingdom
8/6/2011 11:51:21 PM #

From the Continuous Integration/Delivery perspective, surely this is when you create a build pipeline. The actual build process is only the first step and subsequent steps can then mark the artefact as broken. I think that Jenkins supports this for C#.

bearrito United States
8/7/2011 4:24:23 AM #

Absolutely Jenkins supports this.
You can pass in any assembly to FXCop via command line arguments. You can either call it as a post-build step or even a downstream job.

Pingbacks and trackbacks (1)+

Comments are closed