.NET

Recently at the Philly.NET User Group, Kathleen Dollard gave a great presentation on the use of generics and rethinking object orientation. Both topics were very engaging. But the part of the night that I found most intriguing was a conversation, that I had in a Ruby Tuesdays after the presentation, about the useage of static constructors and if they are still a bad thing to use in your code.

Many years ago, I had read the articles by K. Scott Allen and Brad Abrams, explaining why the original FxCop rule, “Do not declare explicit static constructors”, existed and the IL command beforefieldinit, that caused the FxCop rule to trigger and cause performance issues. Jon Skeet explained it best in a recent Stack Overflow post.

Basically, beforefieldinit means “the type can be initialized at any point before any fields are referenced.”

In theory that means it can be very lazily initialized – if you call a static method which doesn’t touch any fields, the JIT doesn’t need to initialize the type.

In practice it means that the class is initialized earlier than it would be otherwise – it’s okay for it to be initialized at the start of the first method which might use it. Compare this with types which don’t have beforefieldinit applied to them, where the type initialization has to occur immediately before the first actual use.

But, I had assumed that since this rule was never include in the Code Analysis (FxCop replacement) part of Visual Studio 2005, 2008, or 2010 that it was a non issue in .NET 2.0 and forward. Since all these previous credible articles that I could find were run against the .NET 1.1 framework. But I had never really looked in to it until now. The first thing I did was create the following program to test 8 different senarios where a static constructor could be created by the compiler or was created by me to test the performance differences.

Program.cs

Each of the 8 senarios had a public interface like the following:

class StaticX
{
    static string Name = "Nick Berardi";
    static string GetName() { /* to make sure the Name property was referenced */ }
}

The scenarios were broken down as follows:

Static1: static class, name set on field
Static2: static class, name set in constructor
Static3: static class, name set in property
Static4: static class, name set on field and in constructor
Static5: name set on field
Static6: name set in constructor
Static7: name set in property
Static8: name set on field and in constructor

Static Constructor Test I then used reflector to give me the following IL dump of the code.

Program.il

If we look at the IL code for each of these classes and static constructors we start finding some interesting patterns in how the compiler optimizes the code.

Static1, Static2, Static5, and Static6

All the the following static constructor (.cctor()), which is interesting because half of them defined the code in the static constructor and half defined the code by setting the field during initialization.

.method private hidebysig specialname rtspecialname static void .cctor() cil managed
{
    .maxstack 8
    L_0000: ldstr "Nick Berardi"
    L_0005: stsfld string ConsoleApplication1.Program/Static1::Name
    L_000a: ret 
}

Static3 and Static7

These do not have any static constructor, which we could have probably guessed because there was no constructor defined and no fields set during intialization of the classes.

Static4 and Static8

These do not match any of the other static constructors we have seen, probably because there is an operating occurring in them.

.method private hidebysig specialname rtspecialname static void .cctor() cil managed
{
    .maxstack 8
    L_0000: ldstr "Nick"
    L_0005: stsfld string ConsoleApplication1.Program/Static8::Name
    L_000a: ldsfld string ConsoleApplication1.Program/Static8::Name
    L_000f: ldstr " Berardi"
    L_0014: call string [mscorlib]System.String::Concat(string, string)
    L_0019: stsfld string ConsoleApplication1.Program/Static8::Name
    L_001e: ret 
}

There is one more place we are going to want to pay attention to before we start looking at the performance, and I sort of alluded to this at the beginning of the article. That is the IL for the class definition:

.class abstract auto ansi sealed nested public beforefieldinit Static1
.class abstract auto ansi sealed nested public                 Static2
.class abstract auto ansi sealed nested public beforefieldinit Static3
.class abstract auto ansi sealed nested public                 Static4
.class          auto ansi        nested public beforefieldinit Static5
.class          auto ansi        nested public                 Static6
.class          auto ansi        nested public beforefieldinit Static7
.class          auto ansi        nested public                 Static8

Please note that I added in the spaces to show the differences between the definitions.

You will notice that the abstract and sealed are missing from Static5 – Static8, don’t worry about those keywords they are the difference between a static class and an instantiatable class. The one we are about is beforefieldinit, which is only added to classes that don’t already contain a static constructor. The definition of how this works has changed slightly from the original specification (ECMA-335). Here is the break down as related to .NET Framework releases:

1st Edition (December 2001) – .NET 1.0
2nd Edition (December 2002) – .NET 1.1
3rd Edition (June 2005) – .NET 2.0, .NET 3.0, .NET 3.5
4th Edition (June 2006) – .NET 2.0, .NET 3.0, .NET 3.5 (Changes from the previous edition were made to align this Standard with ISO/IEC 23271:2006.)

I have marked changes that have been added since the first edition.

The semantics of when and what triggers execution of such type initialization methods, is as follows:

A type can have a type-initializer method, or not.

A type can be specified as having a relaxed semantic for its type-initializer method (for
convenience below, we call this relaxed semantic BeforeFieldInit).

If marked BeforeFieldInit then the type’s initializer method is executed at, or sometime before,
first access to any static field defined for that type.

If not marked BeforeFieldInit then that type’s initializer method is executed at (i.e., is triggered
by):

first access to any static field of that type, or

first invocation of any static method of that type or

first invocation of any constructor for that type. (new in 3rd edition)

Execution of any type’s initializer method will not trigger automatic execution of any initializer
methods defined by its base type, nor of any interfaces that the type implements

START — The following is new to the 3rd edition.
For reference types, a constructor has to be called to create a non-null instance. Thus, for reference types, the
.cctor will be called before instance fields can be accessed and methods can be called on non-null instances. For
value types, an “all-zero” instance can be created without a constructor (but only this value can be created
without a constructor). Thus for value types, the .cctor is only guaranteed to be called for instances of the value
type that are not “all-zero”. [Note: This changes the semantics slightly in the reference class case from the first
edition of this standard, in that the .cctor might not be called before an instance method is invoked if the 'this'
argument is null. The added performance of avoiding class constructors warrants this change. end note]
END

[Note: BeforeFieldInit behavior is intended for initialization code with no interesting side-effects, where exact
timing does not matter. Also, under BeforeFieldInit semantics, type initializers are allowed to be executed at
or before first access to any static field of that type, at the discretion of the CLI.
If a language wishes to provide more rigid behavior—e.g., type initialization automatically triggers execution
of base class’s initializers, in a top-to-bottom order—then it can do so by either:

defining hidden static fields and code in each class constructor that touches the hidden static field of its
base class and/or interfaces it implements, or

by making explicit calls to System.Runtime.CompilerServices.~~Runtime-Helpers~~RuntimeHelpers^{3rd edition}.RunClassConstructor
(see Partition IV).

end note]

So to analyze what has changed, it looks like some major changes took place in the CLR for the .NET 2.0 framework on how and when static constructors should be initialized. In K. Scott Allen’s post that I referenced above he concluded that classes with out the beforefieldinit IL command ran 5 times faster on the .NET 1.1 framework. Lets see if that still holds true for the .NET 2.0 framework (and .NET 3.0 and 3.5 which run off the same CLR as .NET 2.0).

To test this, I ran each of the 8 scenarios through a loop about 2.15 billion times. Or Int32.MaxValue. Then I repeated the process 5 times (for those counting each one was ran about 10 billion times), and averaged the results and came up with these numbers:

Static1: 05.7505114 seconds (static class, name set on field)
Static2: 07.4920393 seconds (static class, name set in constructor)
Static3: 11.6594099 seconds (static class, name set in property)
Static4: 08.3254804 seconds (static class, name set on field and in constructor)
Static5: 05.7362727 seconds (name set on field)
Static6: 07.6593536 seconds (name set in constructor)
Static7: 12.4801669 seconds (name set in property)
Static8: 08.3191176 seconds (name set on field and in constructor)

We can obviously throw out the outliers of setting the name in the property because they where 2 times slower than the fastest method. And we can also throw out the name being set half in the field and half in the constructor, because this is obviously not the best performing and is also not really the best way to code this type of field, and it was only in there as a baseline for doing both a field and constructor setting in the same class.

So lets look at the actual numbers of field vs constructor:

	field	constructor	difference
static class	`05.750511`	`07.492039`	`01.741528`
instantiatable class	`05.7362727`	`07.6593536`	`01.9230809`
difference	`00.014238`3	`00.167314`6

The performance points are pretty much a wash between static class and instantiatable class, and there is essentially no difference between the field and constructor for everyday normal programs to think about changing how you create your static-code as related to fields or constructors. The difference was only 30%, while that sounds like a lot the difference was only 2 seconds over 2.15 billion times run, so we are really talking about fractions of milliseconds per instance. In addition it was no 500% reported by K. Scott Allen against .NET 1.1 back in 2004.

You can draw your own conclusions. But my recommendation is to NOT spend your time changing your code from the use of static constructor to fields, because you won’t find the performance gains in your application. Spend the time on something useful, like the amount of data you are pulling from the database or other places.

I think we can finally put this issue to rest and say that there is no more performance penalty to a degree that every day programmers should care about if you are using the .NET 2.0 framework or forward. Which means I probably guessed correctly as to why they removed it from the Code Analysis rules in Visual Studio 2005.

Update: I had to run each static class individually again to get the correct results, because after I had published this I started playing around with other scenario and noticed that there seemed to be an optimization of static constructor classes (without beforefieldinit), with the same constructor signature, that got loaded later. With the new results, there is now there is virtually no difference between static classes and instantiatable classes which is what I sort of assumed would happen from the beginning.

If anybody knows why static constructor classes that share the same signature would be optimized can you please let me know, this is a new mystery to the static constructor debate.

A question that I have been hearing a lot lately is:

How do I change the view location in MVC?

But what they really mean to say is:

How do I create a new ViewEngine that uses the view locations of my choosing?

It is actually very simple to do, and once you see it, I think you will agree with my assessment. The first thing we are going to do to create our custom ViewEngine, is define the paths that we want to use for our master pages, view pages, and shared pages. I have taken the liberty to define the following paths, you can customize them however you wish:

Master Pages:
~/Templates
it use to be ~/Views/Shared or the controllers view
View Pages:
~/Views
Shared Pages:
~/Common
it use to be ~/Views/Shared

The next thing we need to do is create a new class for our ViewEngine, for this example we are going to call it SimpleViewEngine.

public class SimpleViewEngine : VirtualPathProviderViewEngine
{
}

As you might have noticed from above our SimpleViewEngine inherits from VirtualPathProviderViewEngine, this is the root ViewEngine that uses the VirtualPathProvider (VPP). The VPP provides a way for web applications to read files off the file system in their local web application, so it is perfect for what we are doing. If you don’t want a file system based ViewEngine, and maybe want a ViewEngine based from the database, you can use the IViewEngine interface to create your own custom ViewEngine that fits your needs. (MVC is very flexible, by design)

The next thing we need to do is code our paths in to our SimpleViewEngine. We will do this in the constructor, so that they only have to be initialized once for the entire life span of our SimpleViewEngine.

public SimpleViewEngine () 
{
	/* {0} = view name or master page name
	 * {1} = controller name
	 */

	// create our master page location
	MasterLocationFormats = new[] {
		"~/Templates/{0}.master"
	};

	// create our views and common shared locations
	ViewLocationFormats = new[] {
		"~/Views/{1}/{0}.aspx",
		"~/Common/{0}.aspx",
	};

	// create our partial views and common shared locations
	PartialViewLocationFormats = new[] {
		"~/Views/{1}/{0}.ascx",
		"~/Common/{0}.ascx"
	};
}

As you can see the format is pretty straight forward. We create a string[] array with the paths of where our master pages, views, and common views are located. The only thing that we need to do is set place holders in our path so the the VirtualPathProviderViewEngine can replace the master name, view name, and controller name to construct our appropriate path.

{0}: is the view name or master page name.
{1}: is the controller name.

After we have done the hard part, which honestly wasn’t that hard, of creating the constructor with the paths, we just need to return the view objects from the constructed partial paths. Since we are using the standard ASP.NET Web Form (ASPX/ASCX) rendering engine. We are able to leverage the work already done by the MVC team and just return a new instance of the WebFormView object.

protected override IView CreatePartialView(ControllerContext controllerContext, string partialPath)
{
	return new WebFormView(partialPath, null);
}

protected override IView CreateView(ControllerContext controllerContext, string viewPath, string masterPath)
{
	return new WebFormView(viewPath, masterPath);
}

Nothing really earth shattering here, just simply filling out the constructor with the proper parameters from our method, and then returning the newly created view. If you wanted to create a view based out of the database, or off your own syntax (meaning not ASP.NET syntax) then you would have to create your own view based off of the IView interface. But for this example we are only concerned with changing where our views are located.

There is one more thing that we need to do, and that is register our new SimpleViewEngine for use in the framework. The registration of view engines is done in the Global.asax, similar to the same way we register new routes.

public static void RegisterViewEngines(ViewEngineCollection viewEngines)
{
	viewEngines.Clear();
	viewEngines.Add(new SimpleViewEngine());
}

public static void RegisterRoutes(RouteCollection routes) { ... }

protected void Application_Start()
{
	RegisterRoutes(RouteTable.Routes);
	RegisterViewEngines(ViewEngines.Engines);
}

So we are now done. You have created a new view engines, defined your own routes, and registered this view engine with the MVC framework. Some other types of paths you may want to consider trying for your applications, using a custom ViewEngine, are special folders for your mobile or Facebook versions of your website.

Mobile: ~/Views/{1}/Mobile/{0}.aspx
Facebook: ~/Views/{1}/Facebook/{0}.aspx

I told you it was simple and straight forward, and I hope you agree that the MVC team has done an awesome job at providing a very flexible framework for us to tweak and customize it so it fits our applications.