Which is faster? Comparison or assignment?

Question

I\'m doing a bit of coding, where I have to write this sort of code:

if( array[i]==false )
    array[i]=true;

I wonder if it should be re-w

Answer 1

I really wouldn't expect there to be any kind of noticeable performance difference for something as trivial as this so surely it comes down to what gives you clear, more readable code. I my opinion that would be always assigning true.

Answer 2

I remember in one book about assembly language the author claimed that if condition should be avoided, if possible. It is much slower if the condition is false and execution has to jump to another line, considerably slowing down performance. Also since programs are executed in machine code, I think 'if' is slower in every (compiled) language, unless its condition is true almost all the time.

Answer 3

Might give this a try:

if(!array[i])
    array[i]=true;

But really the only way to know for sure is to profile, I'm sure pretty much any compiler would see the comparison to false as unnecessary and optimize it out.

Answer 4

Why would you even write the first version? What's the benefit of checking to see if something is false before setting it true. If you always are going to set it true, then always set it true.

When you have a performance bottleneck that you've traced back to setting a single boolean value unnecessarily, come back and talk to us.

Answer 5

Well, since you say you're sure that this matters you should just write a test program and measure to find the difference.

Comparison can be faster if this code is executed on multiple variables allocated at scattered addresses in memory. With comparison you will only read data from memory to the processor cache, and if you don't change the variable value when the cache decides to to flush the line it will see that the line was not changed and there's no need to write it back to the memory. This can speed up execution.

Answer 6

As others have noted, this is micro-optimization.

(In politics or journalism, this is known as navel-gazing ;-)

Is the program large enough to have more than a couple layers of function/method/subroutine calls?

If so, it probably had some avoidable calls, and those can waste hundreds as much time as low-level inefficiencies.

On the assumption that you have removed those (which few people do), then by all means run it 10^9 times under a stopwatch, and see which is faster.