CODEWITHSUNDEEP
c#
Pawel
Pawel

Reputation: 604

private static and private methods dilemma

Hi (again with philosophical question),

there is a private static method that does not have an access to instance fields and as far as my readings are concerned those methods provide a little bit of performance improvement.

After you mark the methods as static, the compiler will emit non-virtual call sites to these members. Emitting non-virtual call sites will prevent a check at runtime for each call that ensures that the current object pointer is non-null. This can result in a measurable performance gain for performance-sensitive code. In some cases, the failure to access the current object instance represents a correctness issue.

FxCop

Then why to use normal private method when we can place an instance field in private static method parameters? Isn't that inefficient?

Just to visualize what I mean:

public class A
{
    private readonly string _key = "ssss";

    public bool IsGoodKey()
    {
    }

    private static bool ValidateKeyStatic(string key)
    {
        return string.IsNullOrEmpty(key);
    }
    private bool ValidateKey()
    {
        return string.IsNullOrEmpty(_key);
    }
}

And now there are two ways of implementing IsGoodKey:

    public bool IsGoodKey()
    {
        return ValidateKeyStatic(_key);
    }

And 

    public bool IsGoodKey()
    {
        return ValidateKey();
    }

Why don't always use private static?

Upvotes: 2

Views: 1461

Answers (2)

InBetween
InBetween

Reputation: 32740

After you mark the methods as static, the compiler will emit non-virtual call sites to these members. Emitting non-virtual call sites will prevent a check at runtime for each call that ensures that the current object pointer is non-null. This can result in a measurable performance gain for performance-sensitive code. In some cases, the failure to access the current object instance represents a correctness issue.

I may be wrong, but I think you are mixing up the "current object pointer is non-null" check and the check of the argument passed into the static method _key in the static call ValidateKeyStatic(_key);

The first refers to the pointer on which you invoke the method. When you write the following call to a non static method:

foo.Bar(blah)

An automatic non null runtime check is inserted for foo and if it happens to be null, you get the infamous ReferenceNullException and your program crashes. This check is avoided if the method is static, hence the performance gain, because the method is not invoked on any particular instance of an object.

And it has nothing to do with what checks or not you may perfomr on blah insisde the method Bar.

Upvotes: 0

MakePeaceGreatAgain
MakePeaceGreatAgain

Reputation: 37000

If performance would be the entire purpose of static, then of course you could make anything static. But actually the keyword isn´t about performance, it´s about semantics - that is does the member belong to the class (and thus all instances), or to a specific instance of your class?

Imagine you´d create multiple instances of your class. If every instance had a _key, you surely need an instance-field, not a static one. If on the other hand all instances share the same key, you could make it static of course.

After all performance is just a side-effect of the keyword and you should never make design-decisions on pure performance-considerations.

Upvotes: 5

Related Questions