theburningmonk.com

I stum­bled across some inter­est­ing dis­cus­sions on how they dif­fer from non-static meth­ods, here’s a sum­mary of what I learnt.

The Sta­tic Keyword

In C# terms, “sta­tic” means “relat­ing to the type itself, rather than an instance of the type”. You access a sta­tic mem­ber using the type name instead of a ref­er­ence or a value, e.g. Guid.NewGuid().

In addi­tion to meth­ods and vari­ables, you can also declare a class to be sta­tic (since C# 2.0). A sta­tic class can­not be instan­ti­ated and can only con­tain sta­tic mem­bers. There are a few rules around sta­tic classes:

• Sta­tic classes always derive from object, you can’t spec­ify a dif­fer­ent base type
• Sta­tic classes can­not imple­ment an interface
• Sta­tic classes can­not have any instance members
• Sta­tic classes can’t declare any con­struc­tors and the com­piler doesn’t cre­ate a para­me­ter­less con­struc­tor by default
• Sta­tic classes are implic­itly abstract, you can’t add the abstract mod­i­fier yourself
• Sta­tic classes may be generic
• Sta­tic classes may be nested, in either non-static or sta­tic classes
• Sta­tic classes may have nested types, either non-static or static
• Only sta­tic, top-level non-generic classes can con­tain exten­sion meth­ods (C# 3.0)

Per­for­mance

This quote from DotNetPerls’s page on sta­tic method just about sums every­thing up:

Here we note that sta­tic meth­ods are nor­mally faster to invoke on the call stack than instance meth­ods. There are sev­eral rea­sons for this in the C# pro­gram­ming lan­guage. Instance meth­ods actu­ally use the ‘this’ instance pointer as the first para­me­ter, so an instance method will always have that over­head. Instance meth­ods are also imple­mented with the cal­lvirt instruc­tion in the inter­me­di­ate lan­guage, which imposes a slight over­head. Please note that chang­ing your meth­ods to sta­tic meth­ods is unlikely to help much on ambi­tious per­for­mance goals, but it can help a tiny bit and pos­si­bly lead to fur­ther reductions.

The arti­cle on CA1823 (see Ref­er­ences sec­tion) offers some insight into the ‘over­head’ men­tioned above:

After you mark the meth­ods as sta­tic, the com­piler will emit non­vir­tual call sites to these mem­bers. Emit­ting non­vir­tual call sites will pre­vent a check at run­time for each call that makes sure that the cur­rent object pointer is non-null. This can achieve a mea­sur­able per­for­mance gain for performance-sensitive code.

As stated above, in any real world appli­ca­tion you’re not likely to ever feel the dif­fer­ence in per­for­mance when you con­vert non-static meth­ods to sta­tic or vice versa. If your appli­ca­tion is not per­form­ing to the level you have come to expect then I’d rec­om­mend using a pro­filer and get an accu­rate pic­ture of what’s going inside your code at run­time. I have used both RedGate’s ANTS pro­filer and Jet­Brains’ Dot­Trace and both will do the job more than sufficiently!

Part­ing Thoughts…

Scott Wis­niewski said in his answer to this Stack­Over­flow ques­tion that in a large project (roughly defined as a project with over 200k lines of code) you should avoid mak­ing meth­ods that ‘can be made sta­tic’ sta­tic because:

In a large code base, how­ever, the sheer num­ber of call sites might make search­ing to see if it’s pos­si­ble to con­vert a sta­tic method to a non sta­tic one too costly. Many times peo­ple will see the num­ber of calls, and say “ok… I bet­ter not change this method, but instead cre­ate a new one that does what I need”.

Whilst this state­ment cer­tainly has some truth to it, avoid­ing sta­tic meth­ods should never be the solu­tion to this par­tic­u­lar prob­lem, espe­cially when you con­sider that there are some very good pro­duc­tiv­ity tools out there that can do this for you! So if you don’t want to waste pre­cious man hours on iden­ti­fy­ing meth­ods to be made sta­tic then you should seri­ously con­sider pur­chas­ing tools such as Resharper.

Sta­tic classes on the hand, impose a few more restric­tions (in The Sta­tic Key­word sec­tion above) which make them dif­fi­cult to incor­po­rate within a highly flex­i­ble struc­ture as they can­not imple­ment inter­faces and do not sup­port poly­mor­phism (can­not derive from a base type). See Mark Rasmussen’s answer to this Stack­Over­flow ques­tion, he goes into detail on a num­ber of draw­backs with using sta­tic classes.

Ref­er­ences:

Dot­Net­Perls on Sta­tic Method

Stack­Over­flow ques­tion – Sta­tic vs. Non-Static method per­for­mance C#

Stack­Over­flow ques­tion – Should C# meth­ods that can be sta­tic static

Stack­Over­flow ques­tion – What is a sta­tic class

Stack­Over­flow ques­tion – When to use sta­tic class

MSDN – Writ­ing faster man­aged code : know what things cost

Code Analy­sis CA1822 : Mark mem­bers as static

Dot­Net­Perls on Sin­gle­ton vs. Sta­tic Class

As you’re debug­ging and step­ping through your code in Visual Stu­dio, you will no doubt have come across the Call Stack win­dow in Visual Studio:

You can get access to the same stack trace infor­ma­tion using the Stack­Trace and Stack­Frame class and this opens up some inter­est­ing pos­si­bil­i­ties. For instance, you can have a Log method which can work out the caller method name as sug­gested in this blog post.

You can find the caller method using the fol­low­ing code:

StackFrame frame = new StackFrame(1);
MethodBase method = frame.GetMethod();

With infor­ma­tion about the caller method in hand you can even do inter­est­ing things such as restrict­ing a method so it’s only callable from par­tic­u­lar class or method:

if (method.DeclaringType != typeof(MyClass) || !method.Name.Equals("Mymethod"))
{
    throw new Exception();
}

Lim­i­ta­tions

There are some impor­tant lim­i­ta­tions you need to con­sider when using the Stack Track, these are dis­cussed in more details in the sec­ond post I’ve included in the ‘Ref­er­ences’ sec­tion. In short, it’s not guar­an­teed to give you the result you’d expect as result of com­piler opti­miza­tion when you make a Release build. And you require infor­ma­tion from the source file such as the line num­ber, etc. you will need to gen­er­ate the sym­bols (.pdb file) and make sure it’s included in the release package.

Ref­er­ences:

Get­ting the Cur­rent Stack Trace

Caveats about System.Diagnostics.StackTrace

JIT Opti­miza­tion: Inlining

In C# there is no way to define a sta­tic method in an interface:

interface IMyClass
{
    void MyMethod();  // this is fine
    static int MyStaticMethod();  // not allowed..
    static int MyOtherStaticMethod() { return 1; } // not allowed either
}

This lack of sta­tic method can be painful at times, and on the sur­face one feels there is no rea­son why it can’t/shouldn’t be sup­ported by the lan­guage. But after plough­ing through forum dis­cus­sions and numer­ous ques­tions on Stack­Over­flow I start to under­stand why this is the case.

Prac­ti­cally, this is why hav­ing sta­tic method on the inter­face is confusing:

interface IMyClass
{
    static int MyStaticMethod();
}

class MyClassA : IMyClass
{
    static int MyStaticMethod() { return 1; }
}

class MyClassB : IMyClass
{
    static int MyStaticMethod() { return 2; }
}

So what does IMyClass.MyStaticMethod return?

Philo­soph­i­cally, an Inter­face defines a con­tract, when deal­ing with an inter­face you don’t have to know the imple­men­ta­tion details but only what is avail­able on the inter­face. Sta­tic method on the hand, are designed so that you have a well known loca­tion for a method/property and don’t need an instance of the object to work with it.

These two con­cepts are polar oppo­sites, and you can’t mix the two together with­out break­ing polymorphism!