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);


        

Answer 1

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 2

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 3

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 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

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 6

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.