When does it make sense to store the result of a comparison versus recalculating a comparison in terms of speed?

Question

I'd like to have a solid understanding of when (ignoring available memory space) it makes sense to store the result of a comparison instead of recalculating it. What is the tipping point for justifying the time cost incurred by storage? Is it 2, 3, or 4 comparisons? More?

For example, in this particular case, which option (in general) will perform better in terms of speed?

Option 1:

int result = id.compareTo(node.id);

return result > 0 ? 1 : result < 0 ? -1 : 0;

Option 2:

return id.compareTo(node.id) > 0 ? 1 : id.compareTo(node.id) < 0 ? -1 : 0;

I tried to profile the two options myself in order to answer my own question, but I don't have much experience with this sort of performance testing and, as such, would rather get a more definitive answer from someone with either more experience or else a better grasp of the theoretical elements involved.

I know it's not a big deal and that most of the time the difference will be negligible. However, I'm a perfectionist, and I'd really just like to resolve this particular issue so that I can get on with my life, haha.

Additionally, I think the answer is likely to prove enlightening in regards to similar situations I may encounter in the future wherein the difference might very well be significant (such as when the cost of a comparison or memory allocation is either unable to be incurred or else complex enough to cause a real issue concerning performance).

Answers should be relevant to programming with Java and not other languages, please.

I know I've mentioned it a few times already, but PLEASE focus answers ONLY on the SPEED DIFFERENCE! I am well aware that many other factors can and should be taken into account when writing code, but here I want just a straight-forward argument for which is FASTER.

Answer 1

Experience tells me that option 1 should be faster, because you're making just one call to the compare method and storing the result for reuse. Facts that support this belief are that local variables live on the stack and making a method call involves a lot more work from the stack than just pushing a value onto it. However profiling is the best and safest way to compare two implementations.

The first thing to realise is that the java compiler and JVM together may optimise your code how it wishes to get the job done most efficiently (as long as certain rules are followed). Chances are there is no difference in performance, and chances are also that what is actually executed is not what you think it is. One really important difference however is in debugging: if you put a break point on the return statement for the store-in-variable version, you can see what was returned from the call, otherwise you can't see that in a debugger. Even more handy is when you seemingly uselessly store the value to be returned from the method in a variable, then return it, so you may see what's going to be returned from a method while debugging, otherwise there's no way to see it.

Answer 2

Option 1 cannot be slower than 2, if the compiler optimizes then both could be equal, but then still 1) is more readable, compacter, and better testable.

So there is no argument for Option 2).

If you like you could change to final int result = .... Although i expect that the compiler is so clever that the final keyword makes no difference in this case, and the final makes the code a bit less readable.

Answer 3

option1 one always preferred one ,because here the real world scenarion

----->ok lets

1) thread exceution at id.compareTo(node.id) > 0 ? 1 , in this process some other thread

changes the value of node.id right after id.compareTo(node.id) > 0 ? 1 before going to

id.compareTo(node.id) < 0 ? -1 : 0 this check , the result not identical?

performance wise option1 has more performance when there is bit of functionality exisist in checking.

Answer 4

When does it make sense to store the result of a comparison versus recalculating a comparison in terms of speed?

Most of the time, micro-optimizations like option #1 versus option #2 don't make any significant difference. Indeed, it ONLY makes a significant performance difference if:

• the comparison is expensive,
• the comparison is performed a large number of times, AND
• performance matters.

Indeed, the chances are that you have alrady spent more time and money thinking about this than will be saved over the entire useful lifetime of the application.

Instead of focussing on performance, you should be focussing on making your code readable. Think about the next person who has to read and modify the code, and make it so that he/she is less likely to misread it.

In this case, the first option is more readable than the second one. THAT is why you should use it, not performance reasons. (Though, if anything, the first version is probably faster.)