Usage of Q_UNLIKELY and Q_LIKELY

[Momergil]

Hello!

I would like to know to which extend is recommend to use Q_UNLIKELY and Q_LIKELY in one's code, that is, exactly which situations I should consider "likely" or "likely" to happen so it may present an advantage on using such macros?

In the Qt Assistant, the example given is one in which the user selects a file and tries to open it. In such situation is almost impossible for the file mysteriously be deleted between the user selecting the file and the application trying to open it, "a chance in one million". But lets say that I have a situation in which a occurrence of a "negative" event (negative related to the macro being used between those two) is far more likely or even certain to occur in some point. For example, a loop for of 10, 100 or 1000 iterations where the validation conditional (the expression that falls in the middle of the for, or even the expression inside while()) is therefore going to be hit in 1/10, 1/100 or 1/1000 of the times. In such situations is it still valid to use those two macros or maybe they will even slow down the code or something else?


Thanks,

Momergil

[anda_skoa]

I wouldn't use those in application code unless profiling has shown that the condition and the respective branch decision is indeed a bottle neck.

Then you can always evaluate if the usage of the macro improves the situation.

Cheers,
_

[Momergil]

I wouldn't use those in application code unless profiling has shown that the condition and the respective branch decision is indeed a bottle neck.

\o/ Why such a restricted usage field? Isn't Q_UNLIKELY and Q_LIKELY supposed to improve the code performance? o.O At least for embedded systems, I'ld expect that the best was to put it in the entire code :)

[wysota]

The effect of the macro is that if the CPU supports it, it will read into its pipeline the next instruction after the branch (jump, if you will) before the test result is calculated which saves a cpu cycle (or maybe more, I don't know). If your prediction is incorrect, the pipeline has to be cleared before the proper instruction can be read into the CPU pipeline which harms performance. So first of all, the benefit of using "likely" is not that big, it is not effective on any CPU and the penalty of missing the condition too often is greater than the gain from hitting the condition once in a while. The actual numbers depend on the CPU architecture so nobody will tell you if you should use the modifier when you have a hit ratio over 90%, 99% or 99.9%. If you have a loop that iterates 10k times and you have an average hit ratio of 90% then it is probably worth considering putting a "likely" statement in there. But if you have just 10 iterations and there is an average 90% hit ratio then the gain is so little, you probably waste more energy thinking about optimizing the code than you save by actually doing the optimization.