The often known as likely and unlikely macros help the compiler know whether an if is usually going to be entered or skipped. Using it results in some (rather minor) performance improvements.
I started using them recently, and I'm not sure how often should such hints be used. I currently use it with error checking ifs, which are usually marked as unlikely. For example:
mem = malloc(size);
if (unlikely(mem == NULL))
goto exit_no_mem;
It seems ok, but error-checking ifs happen quite often and consequently the use of the said macros.
My question is, is it too much to have likely and unlikely macros on every error-checking if?
While we're at it, what other places are they often used?
Edit: Even though my question is more general, but in my current usage it's in a library that makes an abstraction from the real-time subsystem, so programs would become portable between RTAI, QNX and others. That said, most of the functions are rather small and directly call one or two other functions. Many are even static inline functions.
So, first of all, it's not an application I could profile. It doesn't make sense to "identify bottle-necks" since it's a library, not a standalone application.
Second, it's kind of like "I know this is unlikely, I might as well tell it to the compiler". I don't actively try to optimize the if.
likelyandunlikelyexist and what they do. I didn't find anything that would actually suggest when and where it is best to use them. – Shahbaz Mar 1 at 13:25