4

I recently read a StackOverflow question that indicated, when accessing variables, it is faster to use the stack than the heap:

void f() {
    int x = 123; // <- located in stack
}

int x; // <- located in heap
void f() {
    x = 123  
}

However, I can't work it through my head which is faster in my example (since I assume they are both using the stack). I'm working on hitbox calculation and such, which uses alot of X-Y, width, height variables (up to 10-20 times for each) in the function.

Is it faster to use an object's get() method each time or set it to a local variable at the start of the function?

In code, is it faster to (or more efficient to):

void f() {
    doSomething(foo.getValue() + bar.getValue()); 
    doSomethingElse(foo.getValue(), bar.getValue());
    doAnotherThing(foo.getValue(), bar.getValue());
    // ... <- lot's of accessing (something.getValue());
}

or

void g() {
    int firstInt = foo.getValue();
    int secondInt = bar.getValue();

    doSomething(firstInt + secondInt);
    doSomethingElse(firstInt, secondInt);
    doAnotherThing(firstInt, secondInt);
    // ... <- lot's of accessing firstInt and secondInt
}

when foo and bar are MyObject's

public class MyObject {
    int x = 1;
    public int getValue() {
        return x;
    }
}

If they are about the same efficiency, how many times do I have to perform a .getValue() for it to become less efficient?

Thanks in advance!

Community
  • 1
  • 1
snickers10m
  • 1,709
  • 12
  • 28
  • 1
    Please don't try and optimize your code like this. First make it work... in general, these micro-optimizations are meaningless. You need to benchmark changes in real code to determine if they matter for your use case. – Elliott Frisch Dec 23 '13 at 19:37
  • 4
    Why does it make a difference? Please google search "premature optimization". – Jim Garrison Dec 23 '13 at 19:37
  • 1
    If you want to know where the turning point is for efficiency, you'll need to conduct a proper microbenchmark yourself. The answer varies with your hardware and your software. – Chris Hayes Dec 23 '13 at 19:40
  • I'm sure I'm not the only one that was unaware of the existence of benchmarking. My code does work, so I was simply asking if it does make a difference, and if anyone knew, what the difference was. – snickers10m Dec 23 '13 at 19:50
  • This isn't necessarily a micro-optimization. `getValue` sounds like a local accessor, so the difference probably isn't too big, but it were `getValueFromDatabase` or `getExpensiveToComputeValue`, the difference would be noticeable pretty early on. There's also readability; if `a` and `b` are replaced with better names, `doSomething(foo,bar)` is much more descriptive than `doSomething(e.getValue,g.getValue)`. – Joshua Taylor Dec 23 '13 at 20:00
  • 1
    I wouldn't trust the post you link. Measure properly and you will most certainly find no difference... – assylias Dec 23 '13 at 20:01
  • @JoshuaTaylor Yes, it's a local accessor, thank you for the qualification. Also, I will make sure to improve the readability of my posts. – snickers10m Dec 23 '13 at 20:15
  • @snickers10m Oh, I didn't mean that _your_ post was unreadable. I meant that using local variables can increase code readability. Your post was fine. – Joshua Taylor Dec 23 '13 at 20:30

2 Answers2

11

JIT will change (optimize) your code on runtime, so this is not important in Java. One simple JIT optimization is method inlining.

For further optimization read about Micro Benchmarking and look at this question How do I write a correct micro-benchmark in Java?

Community
  • 1
  • 1
MariuszS
  • 30,646
  • 12
  • 114
  • 155
0

If you do use local variables, you may tell the compiler that the value will not be changed final int x = ...;, turning it in some kind of local constant.

Reassigning values (recycling objects and such) may help reduce garbage collection (GC).

Write some extreme stress test, if possible a visual one too, let it run for a long time and measure real performance, perceived performance. A better faster time is not always better, sometimes it may be a bit slower but a bit smoother across the execution.

Christophe Roussy
  • 16,299
  • 4
  • 85
  • 85