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

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 2

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 3

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 4

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

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 7

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 8

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.