Question

The documentation seems to be wrong. Could someone tell me which is true?

In Performance Myths section is:

On devices without a JIT, caching field accesses is about 20% faster than repeatedly accesssing the field. With a JIT, field access costs about the same as local access.

In Avoid Internal Getters/Setters section is:

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.

It’s clear that without JIT local access is faster. It’s also clear that accessing field is faster while accessing directly than with getter.

But why in the first case performance is 20% better and in the second case performance is 133% better for the same reason, that is JIT optimization for calling object field?

Answer 1

I think you’re comparing apples and oranges. the Performance Myths reference discusses the advantage of a JIT for field access, while the second reference discusses the advantage of a JIT for method access.

As I understand it, an analogy for direct field access vs. local access (not local field access as you wrote in your post – there is no such thing as a local field) is the following:

class foo {
    int bar = 42;

    int doStuff(){
        int x = 1;
        x += bar;
        x += bar;
        x += bar;
        return x;
    }
}

Each reference to bar has an associated performance cost. A good compiler will recognize the opportunity for optimization and ‘rewrite’ the code as such:

int doStuff(){
    int x = 1f;
    int local_bar = bar;
    x += local_bar;
    x += local_bar;
    x += local_bar;
    return x;
}

Without a JIT, this is a handy optimization, which gets you a 20% bump in performance.

With a JIT, the optimization is unneccessary, as the JIT removes the performance hit from the access to bar in the first place.

The second reference describes the following scenario:

class foo {
    int bar = 42;

    int getBar() { return bar; }

    int doStuff(){
        int x = 1;
        x += getBar();
        x += getBar();
        x += getBar();
        return x;
    }
}

Each function call has an associated performance penalty. A compiler can NOT cache the multiple getBar() method calls (as it cached the multiple direct field accesses to bar in the previous example), because getBar() might return a completely different number each time it is called (i.e. if it had a random or time-based component to its return value). Therefore, it must execute three method calls.

It is vital to understand that the above function would execute at approximatley the same speed with or without a JIT.

If you were to manually replace getBar() in the above function with simply bar, you would achieve a performance boost. On a machine without a JIT, that performance boost is roughly 3x, because field access is still somewhat slow, so replacing the very slow methods with somewhat slow field accesses only yields a moderate boost. With a JIT, however, field access is fast, so replacing the very slow methods with fast field access yields a much greater (7x) boost.

I hope that makes sense!