Store values or calculate values [closed]

Question

We're talking about fairly anal levels of optimisation here that I wouldn't really worry about in anything other than mobile games. Let's say for example you were drawing a texture to the screen in a fairly constant position and the position of that texture could easily be calculated or stored.

I'd be interested to know what professional game developers default to in the first instance when writing code. Which of the two options below would to achieve higher performance in a majority of situations. My main development language is Java.

So option 1 is something like:

constructor {
  x = container.left + offset.x;
  y = container.bottom + offset.y;
}

paint {
  draw(texture, x, y);
}

And option 2 is something like

paint {
  draw(texture, container.left + offset.x, container.bottom + offset.y);
}

With option one the advantage is obviously that the values are pre-calculated. The disadvantages being you're using more RAM and as such there's an increased risk that the data you need wont be in the CPU cache. You also need to make sure the position is recalculated every time there's any movement.

With option two less RAM is used and therefore it's more likely data will be in the CPU cache, but there's the overhead of the calculation. We also don't need to worry about recalculation when there's movement.

Answer 1

The real implications in performance here depend 100% on the platform used.

Say you have written code as in option 2.

When using a statically compiled language such as C++ the compiler will presumable not notice that container.left + offset.x is constant for as long as the object lives and it will not optimize it. When using a language that uses Just-In-Time compilation the code can be optimised at run-time when the compiler sees that the code is on the hot path and it can deduce (thanks to more information being available) that the value is constant. Allowing it to trade memory for speed. If the Jitter will actually make this decisions depends on a very complex set of rules. Here is an interesting article about the optimisations the JIT-compiler can make. Though I am still looking for the definitive source on this from Microsoft.

That being said, these kind of performance questions are almost never worth thinking about. The only real applications that benefit from these performance 'enhancements' are micro-controllers. If you're ever worried about performance use a profiler. I've been writing performance intensive code for many years and I find I can still be surprised by what part of the code is on the hot-path, and actually slowing things down.

First worry on writing code, then worry about the algorithmic complexity of the code on the hot-path, if that is still not enough dive in, trade memory for speed, investigate cache-misses and inspect the generated assembly.

Answer 2

The only way to know for sure is to try both ways, as they can both be faster than each other in different circumstances. The first can be faster because less computation is done, the second can be faster because data is smaller which normally helps avoid costly cache misses. It depends totally on the context. Put another way, I could construct one benchmark that would show the first to be faster, and another benchmark to show the second is faster.

Personally, I default to the second way since it's easier to read (assuming the 'real' program 1 would have the constructor and paint method placed further apart in source). In cases where profiling hasn't been done and seems unlikely to make a large impact either way, I'll always pick the option that's most readable.