I think that the performance of the C# and VB.NET compilers are truly awesome. The 30.000 C# LOC (Lines of Code are expressed in terms of PDB sequence points as defined here) of the VisualNDepend project are compiled in 5 seconds on a regular CoreDuo 32bits 2GB computer. In fact, most of the time it takes even less than a second thanks to the caching optimization provided by the C# compiler/VisualStudio. This performance highly increases our productivity, not only because it saves time, but also because it saves a lot of frustration.

My main activity, apart developing NDepend, consists in auditing projects of tiers company. I’m always amazed to see that most of real-world C# and VB.NET app take minutes or even dozens of minutes to be compiled.  Although it could be justified for monolithic huge application (>500K LOC) it appears that this performance problem arise on small projects that should take seconds to be compiled. I also noticed that this poor performance is widely accepted because people often come from C++ where compilation durations were hours.

I mainly identified 3 causes that each can dramatically slow down compilers. When these causes are pipelined, seconds are transformed in minutes and the developers’ productivity and motivation decrease significantly.

• First, developers should make few big projects instead of numerous small projects. I didn’t find any relevant information on internal compilers optimization, but experience shows that when multiplying the number of projects, the compilation time increase dramatically (10 project of 10K LOC will take much more time to compile than a single project of 100K LOC, I would say around x2). It seems that the unit for compilers’ optimization is the project. Structuring your applications with the adequate grain for assemblies and namespaces is a subject I investigated within this article.

• Second, the referenced assemblies option ‘Copy Local’ is deemed as a good practice. It allows exhibiting for each of your assembly the set of assemblies it transitively depends on. However, we have to realize that this practice triggers numerous file copies behind our back and here also it seems that it enormously hampers compiler optimizations. My advice is to always set ‘Copy Local’ to false and to toss all your assemblies in a single folder such as ${AppFolder}$\bin\Debug and ${AppFolder}$\bin\Release. Not only you’ll accelerate compilation, but also you’ll rationalize the entire development process by minimizing the overall number of files under your precious ${AppFolder}$. Here also experience shows a gain of x2 to x3.

• Third, the source code manager system can also disturb the compilers’ optimization work. I experienced a x3 to x4 penalty when using ClearCase’ dynamic views mode. This point should be investigated carefully because each source code manager system has its strengths and weaknesses. You should be aware that if you experience abnormal long compilation duration, rationalizing the way your source code manager system is used (with a snapshot mode for example) can dramatically help you.

Of course, having big assemblies, don’t use copy local and getting rid of some cool source code manager facilities can be a difficult choice to do, especially when the number of developers working concurrently is high. But it seems to be the price to pay to save a lot of precious time.