Performance of static properties/functions

is there a difference in performance when making properties static/shared that were instance properties before, maybe any locking mechanisms?

There is a heavily used object in HttpCache which was accessible through a property in a page-instance(Service.aspx). Now i wonder if it would be better to make it static because the HttpCache is shared across the application anyway.

The main reason i decided to make it static was because it is simpler to reference(Service.dsRMA vs. ((Service)Page).dsRMA).

I'm aware of the problems that can occur regarding static functions and thread safety.

Thank you fo开发者_开发问答r your time.

Before:

C#

public ERPModel.dsRMA dsRMA {
    get {
        if (Cache("DS_RMA") == null) {
            Cache("DS_RMA") = new ERPModel.dsRMA();
        }
        return (ERPModel.dsRMA)Cache("DS_RMA");
    }
}

VB

Public ReadOnly Property dsRMA() As ERPModel.dsRMA
    Get
        If Cache("DS_RMA") Is Nothing Then
            Cache("DS_RMA") = New ERPModel.dsRMA
        End If
        Return DirectCast(Cache("DS_RMA"), ERPModel.dsRMA)
    End Get
End Property

After:

C#

public static ERPModel.dsRMA dsRMA {
    get {
        if (HttpContext.Current.Cache("DS_RMA") == null) {
            HttpContext.Current.Cache("DS_RMA") = new ERPModel.dsRMA();
        }
        return (ERPModel.dsRMA)HttpContext.Current.Cache("DS_RMA");
    }
}

VB

Public Shared ReadOnly Property dsRMA() As ERPModel.dsRMA
    Get
        If HttpContext.Current.Cache("DS_RMA") Is Nothing Then
            HttpContext.Current.Cache("DS_RMA") = New ERPModel.dsRMA
        End If
        Return DirectCast(HttpContext.Current.Cache("DS_RMA"), ERPModel.dsRMA)
    End Get
End Property

You're unlikely to notice any significant performance difference either way. (If anything, I would expect the static version to have a slight performance benefit. Benchmark to see what happens in your particular situation if the micro-optimisation is genuinely important.)

I would recommend doing whatever makes the most semantic sense in the context of your application domain: If the object logically belongs to a particular instance then use an instance property; if the object is shared between all instances then use a static property.

If there isn't any threading or management issue, static methods are faster (not very faster), in fact instance methods are static methods with implicit this parameter.

Edit: by saying static methods and instance methods different is this, I didn't mean the way of calling, first one is managed in heap and second one in stack.

I have an article here which outlines various locking approaches. This was initially written for BizTalk but applies to general .NET.

I have explained double if sandwitching the lock statement which prevents race conditions. And that is the TopCache in the article. Just read the bottom third of the article.

UPDATE

One word on static method performance. Static method is called by CLR call while instance methods are normally called by callvirt. callvirt which is a virtual call has to go up the inheritance hierarchy to find out which methods to call. This will cause some overhead but it is almost negligible. There are exceptions (for example explicit interface implementation) which is outside scope of this question.

From CLR via C#:

The callvirt IL instruction can be used to call instance and virtual methods, not static methods. When the callvirt instruction is used to call an instance or virtual method, you must specify a variable that refers to an object. When the callvirt IL instruction is used to call a non-virtual instance method, the type of the variable indicates which type defines the method that the CLR should call. When the callvirt IL instruction is used to call a virtual instance method, the CLR discovers the actual type of the object being used to make the call and then calls the method polymorphically. It order to determine the type, the variable being used to make the call must not be null. In other words, when compiling this call, the JIT compiler generates code that verifies that the variable's value is not null. If it is null, the callvirt instruction causes the CLR to throw a NullReferenceException. This additional check means that the callvirt IL instruction executes slightly more slowly than the call instruction. Note that this null check is performed even when the callvirt instruction is used to call a non-virtual instance method.

Static methods are slightly faster than instance methods (See this question). Instance methods have an additional null ref check before invoking the method on the target object.

But that said, this difference is neglible unless the call is in a hot spot (called frequently).