Static methods slower?

[Christof Nordiek]

Actually the this pointer is not passed on the stack, managed code used
the CLR calling convention when calling instance methods, here the this
pointer and the first argument (if any) are passed in a register.

Willy.

Even then, the instance method has one parameter more. depending on the size
of the parameter list, this will use extra space on stack, and the passing
of the parameter surely takes time, even if it is to the register.

Christof

 

[Christof Nordiek]

Static methods should (as a general rule) be thread-safe. In the vast
majority of cases this is a non-issue, since the method is a utility
method that only acts on it's arguments so is inherently thread-safe
without any coding changes or special behaviours.

If, however, the static method talks to static fields etc, then you start
having to add locks

<snip>

Even in this case, omitting the static keyword wouldn't solve the issue.
If the rest of code remains the same, the threading problems would be the
same. The threading issue arises, because the threads share state (static
fields f.e.). Not because the method is declared static.

 

[Marc Gravell]

CN> The threading issue arises, because the threads share state
(static
CN> fields f.e.). Not because the method is declared static.

Which is exactly what I was suggesting when I said:

MG> And equally, this is no different to if this was implemented
MG> as an instance method, where the same instance was
MG> shared between threads (for whatever reason).

Yes, there are other ways of sharing state, but I don't think I ever
suggested that "static" was the cause... just that a static
implementation can (under some designs) lead to that outcome.

Marc

 

[Christof Nordiek]

CN> The threading issue arises, because the threads share state (static
CN> fields f.e.). Not because the method is declared static.

Which is exactly what I was suggesting when I said:

MG> And equally, this is no different to if this was implemented
MG> as an instance method, where the same instance was
MG> shared between threads (for whatever reason).

No, the thread issue remains the same, even if it is called on different
instances. Since the common state is not in the instance field. (Inly if one
changed the fields! to !instance also. But then the semantic is different.

Christof

 

[Marc Gravell]

No, the thread issue remains the same, even if it is called on

different instances

Despite starting with "No", I think your point is actually just a
re-statement
of my original post. I think we are talking the same thing here...

The semantic change is precicely /why/ I stated (for this scenario) a
shared
instance (I didn't state such, but my intention here is using
instance-specific
state with the instance-specific method). I didn't want to suggest
that using
an instance method would somehow solve the problem on its own.
Thread-specific state is clearly different, and would typically be
implemented
by virtue of separate instances. All of this I already stated.

Marc

 

[Willy Denoyette [MVP]]

Even then, the instance method has one parameter more. depending on the size of the
parameter list, this will use extra space on stack, and the passing of the parameter
surely takes time, even if it is to the register.

Christof

Not sure what parameter are you talking about.
The 'this' pointer is passed (in register ESI on X86) as the first argument in case of an
instance method, the first method parameter (if any) is also passed in a register. So as
long as the number of method parameters is < 2 for instance methods and < 3 for static
methods, nothing gets passed through the stack.
So static methods have some less overhead only when the number of arguments is >2, the
instance call overhead is so low that it's nearly impossible to measure the difference on
modern processors, and on X64 where you have some more registers to spare there isn't any
difference at all.

Willy.


Willy.