Should I check a bool before I write it?

Started by
20 comments, last by Ezbez 16 years, 2 months ago
Hi there, maybe this question sounds strange but it just came to my mind and I found no reasonable answer... I have a routine which gets calles quite often. Everytime the function gets called I have to set a boolean variable to true (it does not matter why I have to do this). Is it better/faster to first check if the boolean variable is false and if so, write true to it and if not, just continue without writing? Or does this tiny check not matter at all? Basically it is: a = true; or if (!a) a = true; Thanks in advance, Tom
Advertisement
If it's always going to be set to true, just set it and don't check it.
Have you identified this as any sort of bottleneck in your program? Its extremely unlikely that it is, so I wouldn't bother with it. Just set it to true, and be done with it.
Short answer: Just write it regardless.

Long answer:
In case of dirty flags, the test doesn't make sense.

If you're using something else however, there's two possibilities. One is where the value you're writing is big, and the cost of write is non-negligible. A class requiring deep copy and memory allocations. In that case, testing for equality might save some time.

Another case where this could save time, although very limited, is if the test would perform cache warm-up. By first testing it, you'd ensure that the destination you're writing to is in cache. But this would only give you benefits if you'd need to write multiple, co-located values. For example, when setting an array of bools, accessing (reading) first and last value would improve your chances of having entire array located in L1, and then writing entire array at once.

In your particular case, testing for a value requires a branch, which despite triviality of instructions involved, could decrease performance.

Lastly - it's a freeking 8-bit bool value. Just write it. It's not something that will show up in profiler - ever. The overhead from function call and memory access (possibly L1 and L2 cache miss) can be *thousands* of times bigger than just setting the value.
ok, thanks :)
It is not a bottleneck in my program.

May thought was that writing may be more expensive than reading
The performance impact of the if statement would be so tiny, it's not even worth discussing. Also, the if statement does nothing anyway so get rid of it.
I will do, thanks
Quote:Original post by Antheus
In your particular case, testing for a value requires a branch, which despite triviality of instructions involved, could decrease performance.

QFE. Avoid branches whenever possible.
What do you mean with branch? Is it that there is the if-statement which causes some kind of "subroutine"?
Quote:Original post by VooDooTom
What do you mean with branch? Is it that there is the if-statement which causes some kind of "subroutine"?


Branch Prediction

basically, the CPU tries to guess(based on various things) if a branch is taken or not, in order to try to keep the pipeline full, which allows for faster instruction execution (ie, it can fetch instructions before they are processed). However, if it makes a mistake, it has to empty the pipeline and then refill it, which can potentially take many cycles.

This topic is closed to new replies.

Advertisement