Are Java static calls more or less expensive than non-static calls?

Question

Is there any performance benefit one way or another? Is it compiler/VM specific? I am using Hotspot.

Answer 1

It is unbelievably unlikely that any difference in the performance of static versus non-static calls is making a difference in your application. Remember that "premature optimization is the root of all evil".

Answer 2

In theory, less expensive.

Static initialization is going to be done even if you create an instance of the object, whereas static methods will not do any initialization normally done in a constructor.

However, I haven't tested this.

Answer 3

First: you shouldn't be making the choice of static vs non-static on the basis of performance.

Second: in practice, it won't make any difference. Hotspot may choose to optimize in ways that make static calls faster for one method, non-static calls faster for another.

Third: much of the mythos surrounding static versus non-static are based either on very old JVMs (which did not do anywhere near the optimization that Hotspot does), or some remembered trivia about C++ (in which a dynamic call uses one more memory access than a static call).

Answer 4

Well, static calls can't be overridden (so are always candidates for inlining), and don't require any nullity checks. HotSpot does a bunch of cool optimizations for instance methods which may well negate these advantages, but they're possible reasons why a static call may be faster.

However, that shouldn't affect your design - code in the most readable, natural way - and only worry about this sort of micro-optimization if you have just cause (which you almost never will).

Answer 5

As previous posters have said: This seems like a premature optimization.

However, there is one difference (a part from the fact that non-static invokations require an additional push of a callee-object onto the operand stack):

Since static methods can't be overridden, there will not be any virtual lookups in runtime for a static method call. This may result in an observable difference in under circumstances.

The difference on a byte-code level is that a non-static method call is done through INVOKEVIRTUAL, INVOKEINTERFACE or INVOKESPECIAL while a static method call is done through INVOKESTATIC.

Answer 6

There might be a difference, and it might go either way for any particular piece of code, and it might change with even a minor release of the JVM.

This is most definitely part of the 97% of small efficiencies that you should forget about.

Answer 7

As Jon notes, static methods can't be overridden, so simply invoking a static method may be -- on a sufficiently naive Java runtime -- faster than invoking an instance method.

But then, even assuming you're at the point where you care about messing up your design to save a few nanoseconds, that just brings up another question: will you need method overriding yourself? If you change your code around to make an instance method into a static method to save a nanosecond here and there, and then turn around and implement your own dispatcher on top of that, yours is almost certainly going to be less efficient than the one built into your Java runtime already.

Answer 8

It is compiler/VM specific.

• In theory, a static call can be made slightly more efficient because it doesn't need to do a virtual function lookup, and it can also avoid the overhead of the hidden "this" parameter.
• In practice, many compilers will optimize this out anyway.

Hence it's probably not worth bothering about unless you have identified this as a truly critical performance issue in your application. Premature optimization is the root of all evil etc...

However I have seen this optimization give a substantial performance increase in the following situation:

• Method performing a very simple mathematical calculation with no memory accesses
• Method being invoked millions of times per second in a tight inner loop
• CPU bound application where every bit of performance mattered

If the above applies to you, it may be worth testing.

There is also one other good (and potentially even more important!) reason to use a static method - if the method actually has static semantics (i.e. logically is not connected to a given instance of the class) then it makes sense to make it static to reflect this fact. Experienced Java programmers will then notice the static modifier and immediately think "aha! this method is static so it doesn't need an instance and presumably doesn't manipulate instance specific state". So you will have communicated the static nature of the method effectively....

Answer 9

For the decision if a method should be static, the performance aspect should be irrelevant. If you have a performance problem, making lots of methods static isn't going to save the day. That said, static methods are almost certainly not slower than any instance method, in most cases marginally faster:

1.) Static methods are not polymorphic, so the JVM has less decisions to make to find the actual code to execute. This is a moot point in the Age of Hotspot, since Hotspot will optimize instance method calls that have only one implementation site, so they will perform the same.

2.) Another subtle difference is that static methods obviously have no "this" reference. This results in a stack frame one slot smaller than that of an instance method with the same signature and body ("this" is put in slot 0 of the local variables on the bytecode level, whereas for static methods slot 0 is used for the first parameter of the method).