On Mon, 12 Aug 2024 at 20:34, John Naylor <johncnaylo...@gmail.com> wrote: > I just remembered an article I read a while back by a compiler > engineer who said that compilers have heuristics that treat NULL > pointers as "unlikely" since the most common reason to test that is so > we can actually dereference it and do something with it, and in that > case a NULL pointer is an exceptional condition. He also said it > wasn't documented so you can only see this by looking at the source > code. Instead of taking the time to verify that, I created some toy > examples and it seems to be true: > > https://godbolt.org/z/dv6M5ecY5
Interesting. I agree with Andres' comment about the no increase in binary size overhead. The use of unlikely() should just be a swap in the "call" operands so the standard_Executor* function goes in the happy path. (These are all sibling calls, so in reality, most compilers should do "jmp" instead of "call") I also agree with Tom with his comment about the tests for these executor hooks not being hot. Each of them are executed once per query, so an unlikely() isn't going to make any difference to the performance of a query. Taking into account what your analysis uncovered, I think what might be worth spending some time on would be looking for hot var == NULL tests where the common path is true and seeing if using likely() on any of those makes a meaningful impact on performance. Maybe something like [1] could be used to inject a macro or function call in each if (<var> == NULL test to temporarily install some telemetry and look for __FILE__ / __LINE__ combinations that are almost always true. Grouping those results by __FILE__, __LINE__ and sorting by count(*) desc might yield something interesting. David [1] https://coccinelle.gitlabpages.inria.fr/website/
