Fine Tuning Java Code - Attribute vs Local Variable Access
Summary
Consider using local cache variables when optimising processor intensive loop constructs.
Attribute access vs Local access
Tip 3:
Minimise object attribute access (read/write) by the using a local variable holding a cached value of the attribute (care is required in multi-threaded environment).
A JVM is a multi-threaded runtime platform. Therefore any object may be accessed from different threads at any time. Accessing an attribute is a non atomic operation, and is subject to context switches (updating an object attribute could occur in the middle of the sequence of bytecode that formalises accessing the object attribute).
Let's investigate the following;
public int foo(){
return field;
}
2A // 0 : aload_0
B4 000D // 1 : getfield I A.field
AC // 4 : ireturn
At least two instructions are required to get the attribute before returning (a smart JVM may cache the receiver (a.k.a. aload_0) in a register, so that it becomes a fast access once the code has been JIT compiled). The situation is worsened when an increment is included, as the JVM can use special instruction for int locals (locals are private to one thread).
public int foo(){
return field++;
}
2A // 0 : aload_0
59 // 1 : dup
B4 000D // 2 : getfield I A.field
5A // 5 : dup_x1
04 // 6 : iconst_1
60 // 7 : iadd
B5 000D // 8 : putfield I A.field
AC // B : ireturn
One can take advantage of the fact that accessing a local is much faster than an attribute, this is particularly relevant for loop constructs.
An example illustrates this (field is an attribute of the object, of type int).
public void foo(){
while (field >= 0){
bar(field+field);
field--;
}
}
public void foo_faster(){
int i = field;
while (i >= 0){
bar(i+i);
i--;
}
field = i;
}
Both methods perform the same functionality, except that foo_faster assumes the object is not being accessed concurrently by another thread when it executes the body of the loop - which is almost always true!
---foo---
A7 001A // 0 : goto 1A (offset-10-base = 26)
2A // 3 : aload_0
2A // 4 : aload_0
B4 000D // 5 : getfield I A.field
2A // 8 : aload_0
B4 000D // 9 : getfield I A.field
60 // C : iadd
B6 0012 // D : invokevirtual A.bar(I)V
2A // 10 : aload_0
59 // 11 : dup
B4 000D // 12 : getfield I A.field
04 // 15 : iconst_1
64 // 16 : isub
B5 000D // 17 : putfield I A.field
2A // 1A : aload_0
B4 000D // 1B : getfield I A.field
9C FFE5 // 1E : ifge 3 (offset-10-base = -27)
B1 // 21 : return
---foo_faster---
2A // 0 : aload_0
B4 000D // 1 : getfield I A.field
3C // 4 : istore_1
A7 000D // 5 : goto 12 (offset-10-base = 13)
2A // 8 : aload_0
1B // 9 : iload_1
1B // A : iload_1
60 // B : iadd
B6 0012 // C : invokevirtual A.bar(I)V
84 01 FF // F : iinc local variable 1 by -1
1B // 12 : iload_1
9C FFF5 // 13 : ifge 8 (offset-10-base = -11)
2A // 16 : aload_0
1B // 17 : iload_1
B5 000D // 18 : putfield I A.field
B1 // 1B : return
The majority of processing is taken up in the body of the loop, which must therefore be optimised to increase the speed of method execution.
The loop of foo starts at step 3 and ends at step 1E and comprises 16 instructions. The loop of foo_faster starts step 8 and ends at step 13 and comprises 8 instructions - half the size of the loop of foo!
