Nik talks on technology and change processes

C# Type Constructors and Performance



At the end of my previous post on C# and code explosion within MSIL I had mentioned that when it comes to type constructors or commonly known as “static constructors”  or “class constructors” the beforefieldinit flag can considerably boost the performance of your types. This is my first post in a two part series of posts where I would try to analyze the impact of declaring type constructors on the performance of an application.

If a type has a static constructor defined then the JIT compiler will decide when to call it. A developer does not has the liberty to decide when the constructor code should be executed which is unlike normal constructors which a developer can explicitly call from her code.

Problem

Let me begin by showing you the problem. In the following code sample I have declared two static classes. In one of them I have explicitly declared a static constructor whereas the other does not has an explicit type constructor. Both these classes have an integer field which is exposed to callers within the assembly (bad design I know but the intention is to keep things as simple as possible for this example).

Next I simply run a loop where all I do is set this field to 0 for both types and I log the time this loop takes for both types. Have a look at the code sample below. What do you think the output will be?

 

Code Snippet
  1. #region nik code
  2. using System;
  3. using System.Diagnostics;
  4. namespace TypeConstructors
  5. {
  6.     class WithoutConstructor
  7.     {
  8.         internal static Int32 Counter = 0;
  9.     }
  10.     class WithExplicitConstructor
  11.     {
  12.         internal static Int32 Counter = 0;
  13.         static WithExplicitConstructor()
  14.         {
  15.         }
  16.     }
  17.     class Program
  18.     {
  19.         static void Main(string[] args)
  20.         {
  21.             Program p = new Program();
  22.             ConsoleKeyInfo key;
  23.             int iterations = 2000 * 1000 * 1000;
  24.             do
  25.             {
  26.                 p.Method1(iterations);
  27.                 Console.WriteLine();
  28.                 Console.Write(“Press Y to repeat, any other key to exit: “);
  29.                 key = Console.ReadKey();
  30.                 Console.WriteLine();
  31.                 Console.WriteLine();
  32.             } while (key.Key == ConsoleKey.Y);
  33.         }
  34.         void Method1(int iterations)
  35.         {
  36.             //Console.WriteLine(“Method 1 time lines follow”);
  37.             Stopwatch w = Stopwatch.StartNew();
  38.             for (int i = 0; i < iterations; i++)
  39.             {
  40.                 WithoutConstructor.Counter = 0;
  41.             }
  42.             w.Stop();
  43.             Console.WriteLine(“Time taken by the loop for class with no defined type constructor: {0}”, w.Elapsed.Seconds);
  44.             w = Stopwatch.StartNew();
  45.             for (int i = 0; i < iterations; i++)
  46.             {
  47.                 WithExplicitConstructor.Counter = 0;
  48.             }
  49.             w.Stop();
  50.             Console.WriteLine(“Time taken by the loop for class with the defined type constructor: {0}”, w.Elapsed.Seconds);
  51.         }
  52.     }
  53. }
  54. #endregion

 

 

Here’s screenshot of the output on my machine.

image

As the result shows the type with an explicit type constructor defined took considerably longer to execute as compared to the type with no explicit type constructor defined. This performance hit is constant and repetitive. That is calling the Method1 multiple times will always incur in this performance penalty. This is not a “one off hit”

Before we move onto the discussion of why exactly this is happening let us have a quick look at the MSIL that is generated for the code above. Notice that even though I have not provided an explicit type constructor for the WithoutConstructor class, the compiler adds one which contains identical code as the one for the WithExplicitConstructor class. There is one subtle difference in the MSIL however which I have highlighted in the screenshot. Any guesses what that that might be ;)

MSIL for Type Constructors

Explanation

Right so now we know that using type constructors can severely penalize the performance of a type. Let us now understand why this happens. Before we do that it is necessary to understand how .NET runtime treats type constructors and implicit assurances that the CLR runtime provides.

CLR Assurance

When it comes to type constructors or static constructors the .NET runtime does some pretty clever stuff.

CLR guarantees that a type constructor will only be called once per type in an app domain and further it guarantees thread safety while calling these type constructors. The CLR also guarantees that a type constructor for a type will always be executed before any static or instance field or constructors are run.

This actually makes type constructors very good places to do any kind of singleton initialization stuff – but be careful! This singleton stuff in a static constructor can lead to more problems. I will dedicate a post on that next.

JIT Compiler and Thread Execution

Let us peek under the hood of JIT compiler and see if we can understand how JIT compiler would be spitting out code for a class which has type constructor defined for it. Please remember we are now looking at how native code is being generated by JIT compiler and not MSIL. When JIT compiler is compiling a method that uses a type with type constructor the JIT compiler checks whether this type’s constructor has already been called for this AppDomain. If this constructor has not been called the JIT compiler emits a call to call the type constructor of the type being referenced. If the type constructor has already been called once the JIT compiler skips the instructions to call the type constructor of the type.

The JIT compiler selectively produces the native machine code that runs the type constructor’s code.

At some point after this a thread (or more thread than one) will start executing this native code compiled by the JIT compiler. As I mentioned above the .NET CLR guarantees that type constructors for a type or only called once per AppDomain. Thus when the thread reaches this point of execution it will acquire a mutually exclusive lock, it will then verify that the code within the type constructor has not been executed and finally run the code produced by the JIT compiler to call the constructor. Once this thread is done processing the other threads will wake up. When the next thread reaches this point of execution it will verify whether the type constructor has been called or not. In this instance the thread will know that the code within this type constructor has actually been called and thus the thread will simply return without executing the code.

Before a thread runs the JIT compiled code for a type constructor the thread verifies whether the type constructor’s code has been  run or not. If it has been run then the thread skips executing the type constructor’s code.

When does JIT compiler calls the type constructor then?

So JIT compiler automatically generates instructions to call a type’s type constructor once per AppDomain in a thread safe manner before any static or instance fields of the type evaluated or executed. How does JIT compiler decide when to call the constructor? As it turns out there are two possibilities for JIT compiler

  • The JIT compiler can emit the call sometime before the running code first invokes a non static constructor or references a  static field or static or instance method. This is called “Before-Field-Init” semantics since the only guarantee CLR provides is that the type constructor will run “at some point” before the type is used.
  • Or the JIT compiler can emit the call immediately before the code either first creates the first instance of this type or immediately before the running code accesses the first member of this class. This is called “precise” semantics because CLR calls the constructor precisely at the right time.

The CLR prefers the before-field-init semantic as that gives the CLR quite a lot of flexibility about when to call the type constructor and CLR takes advantage of it by producing optimized code that runs faster. However it comes down a particular compiler on what semantic it wants the CLR to use. Compilers indicate this marking the metadata of a particular type by the “beforefieldinit” flag. The presence of this flag indicates that the CLR would use the Before-Field-Init semantic and the absence of this flag tells CLR to use precise semantics.

Compilers set the “beforefieldinit” flag in the row of type metadatas for the type which tells the CLR to use Before-Field-Init semantics.

Important bits so far

For the sake of clarity let me reiterate the important points so far

  • For type constructors or static constructors CLR makes the choice when to call them. Developer can not directly influence this decision.
  • CLR has two semantics to execute the type constructors for types. These are called Precise and Before-Field-Init semantics. The preference is Before-Field-Init.
  • The CLR run-time will call the type constructor code exactly once per type per AppDomain. Further CLR will ensure thread safety while calling this code
  • JIT compiler while generating native code will also create instructions for the executing thread to verify whether a type constructor has been called or not. If it has been called by a previous thread, the current executing thread does not execute that code.

 

Problem Code Revisited

Let us revisit the code in the light of the above discussion. I have shared the same code again but this time I have added another method (which is the exact copy of the first method) and I have added in-line comments to explain how CLR treats this execution chain.

When the code starts executing the JIT compiler adopts Precise semantics for the WithExplicitConstructor class as the CSC compiler did not add the beforeinitfield flag to this type. Since Method1 is the first method call that uses these types the JIT compiler not only emits the code to call the type constructor for WithExplicitConstructor class within the for loop but as explained above the code to verify whether the constructor code should be executed at all or not is also emitted in this loop! For the other type the JIT optimises the generated code to not have to do the verification within the loop resulting in performance boost.

Code Snippet
  1. using System;
  2. using System.Diagnostics;
  3. namespace TypeConstructors
  4. {
  5.     class WithoutConstructor
  6.     {
  7.         internal static Int32 Counter = 0;
  8.     }
  9.     class WithExplicitConstructor
  10.     {
  11.         internal static Int32 Counter = 0;
  12.         static WithExplicitConstructor()
  13.         {
  14.         }
  15.     }
  16.     class Program
  17.     {
  18.         static void Main(string[] args)
  19.         {
  20.             Program p = new Program();
  21.             ConsoleKeyInfo key;
  22.             int iterations = 2000 * 1000 * 1000;
  23.             do
  24.             {
  25.                 p.Method1(iterations);
  26.                 Console.WriteLine();
  27.                 p.Method2(iterations);
  28.                 Console.WriteLine();
  29.                 Console.Write(“Press Y to repeat, any other key to exit: “);
  30.                 key = Console.ReadKey();
  31.                 Console.WriteLine();
  32.                 Console.WriteLine();
  33.             } while (key.Key == ConsoleKey.Y);
  34.         }
  35.         ///<summary>
  36.         /// When this method starts to execute the JIT compiler adds the native code instructions to execute
  37.         /// the two static constructors within the scope of this method since they have not been run before.
  38.         ///</summary>
  39.         ///<param name=”iterations”></param>
  40.         void Method1(int iterations)
  41.         {
  42.             Console.WriteLine(“Method 1 time lines follow”);
  43.             Stopwatch w = Stopwatch.StartNew();
  44.             for (int i = 0; i < iterations; i++)
  45.             {
  46.                 /* for this class the JIT compiler follows the Before-Field-Init semantics
  47.                  * It is thus able to write the instructoins that verify whether the type constructor has been executed or not and execute it if needed
  48.                  * outside the body of this loop resulting in this loop running faster.
  49.                  * */
  50.                 WithoutConstructor.Counter = 0;
  51.             }
  52.             w.Stop();
  53.             Console.WriteLine(“Time taken by the loop for class with no defined type constructor: {0}”, w.Elapsed.Seconds);
  54.             w = Stopwatch.StartNew();
  55.             for (int i = 0; i < iterations; i++)
  56.             {
  57.                 /* Since the JIT compiler is follwing Precise semantics for WithExplicitConstructor class
  58.                  * it emits the instructions to verify and execute the type constructor at this point.
  59.                  * Each executing thread thus will run the verification logic with each iteration in addition to the
  60.                  * actual type constructor code being run by the first thread that gets here
  61.                  * this results in performance hit since the verification code runs as many times as there are iterations
  62.                  * */
  63.                 WithExplicitConstructor.Counter = 0;
  64.             }
  65.             w.Stop();
  66.             Console.WriteLine(“Time taken by the loop for class with the defined type constructor: {0}”, w.Elapsed.Seconds);
  67.         }
  68.         ///<summary>
  69.         /// When this method is called within the code, the JIT compiler knows that the two types used within the method
  70.         /// have had their type constructors executed earlier on for this AppDomain. The JIT compiler thus does not emit the
  71.         /// calls to verify and execute the two type constructors within the scope of this method.
  72.         /// Thus the two loops within this method run with identical time lines.
  73.         ///</summary>
  74.         ///<param name=”iterations”></param>
  75.         void Method2(int iterations)
  76.         {
  77.             Console.WriteLine(“Method 2 time lines follow”);
  78.             Stopwatch w = Stopwatch.StartNew(); ;
  79.             for (int i = 0; i < iterations; i++)
  80.             {
  81.                 WithoutConstructor.Counter = 0;
  82.             }
  83.             w.Stop();
  84.             Console.WriteLine(“Time taken by the loop for class with no defined type constructor: {0}”, w.Elapsed.Seconds);
  85.             w = Stopwatch.StartNew();
  86.             for (int i = 0; i < iterations; i++)
  87.             {
  88.                 WithExplicitConstructor.Counter = 0;
  89.             }
  90.             w.Stop();
  91.             Console.WriteLine(“Time taken by the loop for class with the defined type constructor: {0}”, w.Elapsed.Seconds);
  92.         }
  93.     }
  94. }

 

 

When the JIT compiler starts producing the native code for Method2 it is smart enough to figure out that the type constructors for both types would have been called in Method1 execution chain. It thus omits spitting the code to verify and execute the type constructors for these types in the Method2 execution scope which results in both types executing with same time lines.

Following is a screenshot from my laptop displaying the execution times for the above sample

Type constructor performane revisited

As a last noted please bear in mind that the performance of the methods is determined by execution order of the code at JIT compilation time. If you switch the two calls Method2 will become the slower method as JIT will emit the verification code in the scope chain of Method2.

Summary

I hope with this article I have succeeded in explaining the hidden performance penalties that can incur while implementing static constructors for classes. As I mentioned in the description above these constructors can also impact the object initialization and disposal time lines when used with Singleton pattern which can lead to objects staying instantiated for prolonged periods on heap. I will try and explain this in the next post.

Sample Code

As always I have uploaded all the code used in this blog post. The archived file is available to download here

4 Comments

  1. Mark Philpott's Gravatar Mark Philpott
    November 5, 2012 at 2:40 pm | Permalink

    Interesting analysis. Was this run in ‘debug’ or ‘release’ mode? If I run it in release mode I get a much more pronounced difference – 1.6s vs. 7.3s.

    However we need to be careful about premature optmisation – if we change the method to do something less trivial (e.g. adding an element to a set) the relative difference is much smaller – 43.0s vs 43.5s in a quick test.

  2. Chok's Gravatar Chok
    November 6, 2012 at 3:14 am | Permalink

    This is one of those things where C# is different from Java. In C#, static constructors are called only when the methods are invoked or when the fields are accessed. In Java, the static constructor is called when the class is referred to. Hence in Java you won’t get this problem. But then, in C#, I think the difference is not really that great. Sounds like an optimization in the CLR would be able to get rid of this kind of performance penalty.

  1. Nik's Corner – C# Constructors and MSIL Code Explosion on November 4, 2012 at 10:36 pm

Leave a Reply

Your email address will not be published. Required fields are marked *


five + 6 =

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">