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.