In Java is there a performance difference between referencing a field through getter versus through a variable?

Question

Is there any differences between doing

Field field = something.getSomethingElse().getField();
if (field == 0) {
//do something    
}
somelist.add(field);

versus

if (something.getSomethingElse().getField() == 0) {
//do something    
}
somelist.add(something.getSomethingElse().getField());

Do references to the field through getters incur a performance penalty or is it the same as referencing an assigned variable? I understand that the variable is just a reference to the memory space, so the getter should just be another way to get at that memory space.

Note that this is an academic question (school of just curious) rather then a practical one.

Answer 1

Assuming that getSomethingElse() is defined as

public SomethingElse getSomethingElse() {
    return this.somethingElse;
}

performance difference will be minimal (or zero if it'll get inlined). However, in real life you can not always be sure that's the case - there may be some processing happening behind the scenes (not necessarily in the object itself but, say, via AOP proxy). So saving the result in the variable for repeat access may be a good idea.

Answer 2

It's a negligible detriment. Don't concern yourself with it too much or you'll fall prey to premature optimization. If your application is slow, this isn't the reason why.

Answer 3

There is a difference in that accessing variables through getters results in a method call. The JVM might conceivably be able to optimize the method call away under some circumstances, but it is a method call.

That said, if the biggest bottleneck or performance problem in your code is overhead from accessor methods, I would say that you don't have a lot to worry about.

Answer 4

There is a performance penalty ( which may be so small it is negligible ) Yet, the JVM may inline this and all the calls to improve the performance.

It would be better if you leave it the second way.

Answer 5

Not if you have a good JVM, like HotSpot from Sun. It will in-line and compile (to native code) the getters.

Using getters is generally a very good practice, as a defensive measure, and general Information Hiding.

Answer 6

One point to note if using Java for writing Android applications is here: http://developer.android.com/training/articles/perf-tips.html#GettersSetters

In native languages like C++ it's common practice to use getters (i = getCount()) instead of accessing the field directly (i = mCount). This is an excellent habit for C++ and is often practiced in other object oriented languages like C# and Java, because the compiler can usually inline the access, and if you need to restrict or debug field access you can add the code at any time.

However, this is a bad idea on Android. Virtual method calls are expensive, much more so than instance field lookups. It's reasonable to follow common object-oriented programming practices and have getters and setters in the public interface, but within a class you should always access fields directly.

Without a JIT, direct field access is about 3x faster than invoking a trivial getter. With the JIT (where direct field access is as cheap as accessing a local), direct field access is about 7x faster than invoking a trivial getter.

Note that if you're using ProGuard, you can have the best of both worlds because ProGuard can inline accessors for you.

Answer 7

If the method is a simple getter with no processing involved it isn't an issue. If it involves extensive calculation, a property wouldn't do what you want anyway.

The only time I'd worry about any difference is in a tight loop with a huge number of iterations (many thousands). Even then this is probably only an issue if you're using aspects to weave extra processing (e.g. logging), this can involve creating thousands of extra objects (e.g. JoinPoints and parameter autoboxing) and resultant GC issues.

Answer 8

I wouldn't worry about the performance difference. You'd be better to not think about it and instead spend time on profiling your code in a realistic scenario. You will most likely find that the slow parts of your program aren't where you think they are.

Answer 9

This post talks about the CLI VM instead of the JVM, but each is able to do similar things, so I believe it's relevant.

I'm handling this particular problem in a special way for my JIT. Note that the description here is conceptual and the code implements it in a slightly different way for performance reasons. When I load an assembly, I make a note in the method descriptor if it simply returns a member field. When I JIT other methods later, I replace all call instructions to these methods in the byte code with a ldfld instruction before passing it to the native code generator. In this way, I can:

1. Save time in the JIT (ldfld takes less processor time to JIT than call).
2. Inline properties even in the baseline compiler.
3. By and large guarantee that using the public properties/private fields pattern will not incur a performance penalty of any kind when the debugger is detached. (When a debugger is attached I can't inline the accessors.)

I have no doubt that the big names in VM technologies are already implementing something similar to (and probably better than) this in their products.