# Store values or calculate values [closed]

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.

## closed as off-topic by Josh♦Oct 7 '14 at 21:03

This question appears to be off-topic. The users who voted to close gave this specific reason:

• "Programming questions that aren't specific to game development are off-topic here, but can be asked on Stack Overflow. A good rule of thumb is to ask yourself "would a professional game developer give me a better/different/more specific answer to this question than other programmers?"" – Josh
If this question can be reworded to fit the rules in the help center, please edit the question.

• The reason this is being asked on the gamedev site is that on Stackoverflow everyone would just scream 'premature optimisation'. Game developers tend to have a better understanding of the need to write efficient code due to real time processing requirement of games. I am therefore explicitly interested in the views of game developers. – Will Calderwood Oct 8 '14 at 7:55
• That doesn't make it on-topic here, I'm afraid. – Josh Oct 8 '14 at 14:50
• @JoshPetrie Can you please explain how asking about best practices when writing games is not a game development topic? – Will Calderwood Oct 8 '14 at 14:54
• The guidance for being on-topic here is not that you are working on a game, it's that game developers are able to give a better answer than any other programmer. That's not true for this particular topic, which is about the general operation of computer hardware and compilers. Further, questions asking for broad "best practices" are discussion-oriented and not appropriate for SE. – Josh Oct 8 '14 at 15:20
• I just voted against reopening this question. Your edits didn't change the fundamental problem (in spite of you working on a game while formulating it). And the issue remains that you aren't trying to solve a problem, but rather begin a discussion about the difference between your two proposed methods. That is not how SE questions are meant to work. – Seth Battin Oct 8 '14 at 15:34

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.

• – Brian S Oct 7 '14 at 15:45

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.

• Thanks. This isn't really about a specific situation, but rather what I should default to. It's not realistic to write every graphical element in the game both ways and profile each one to see which is more efficient. – Will Calderwood Oct 7 '14 at 13:53
• That's what I was getting at with the last sentence really - I would default to the second way unless I had profiled it and had evidence that the first way provides a benefit. But at the same time it's not practical to speculatively profile every part of every program to that depth, so you have to pick the 'likely wins' (or the biggest unknowns) to profile, which is something you only know how to do with experience. This doesn't look like a likely win to me (without knowing the wider context, of course!). So I guess a shorter answer to your question would be "option 2"! – Ben Hymers Oct 9 '14 at 12:01