Benefit from the C# and VB.NET compilers perf

 

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.

 

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Arjan

    Visual Studio 2008 (beta 2) compiles in 13 seconds where 2005 takes 16 seconds :)

  • Arjan

    I tried it by moving 5 projects into 2. It maybe saves me 10% to 20%, no more, this includes the copy local setting. I have about 70.000 lines of C# code and it takes about 16 seconds to complete, on my AMD 3GHz notebook.

  • http://www.peterRitchie.com/blog Peter Ritchie

    Sounds like compiler vendors need to focus their attention on linkers and librarians in terms of performance work…