Attached patch is an attempt to use the GCC/Clang __builtin_expect() attribute to provide the compiler with branch prediction information, it adds _Py_likely() and _Py_unlikely() macros, similar to the Linux kernel macros.

I always wanted to experiment this change. I opened this issue to collect information and benchmark results to take a decision. I doubt that the change will really make Python faster, there is a risk of modifying a lot of code for no value, or worse: make Python slower. Extract of GCC doc:

  "as programmers are notoriously bad at predicting how their programs actually perform."

My patch marks error cases as unlikely. A profiler like Linux perf should be used to check which branches are less likely, but I tried to use my guesses to expeeriment a first change.

Since there is a risk that using such macro makes the code slower, or has no effect, I tried to restrict changes to the hot code and the most common functions/macros:

* Py_EnterRecursiveCall()
* _PyArg_NoKeywords()
* Py_DECREF()... not sure about this case, is it really more likely that refcnt != 0 than refcnt==0?
* Functions to call functions: _PyObject_FastCallKeywords(), fast_function(), etc.
* etc.

I'm not sure about the methodology to benchmark such patch neither. Is it worth it to benchmark a Python compiled without PGO?

By the way, does GCC/Clang use __builtin_expect() information when Python is compiled with PGO? If PGO ignores this information, it would be better to not use it, since I now strongly recommend to use PGO. Otherwise, Python performance is too random because of the joy of code placement.

Some links on __builtin_expect():

* http://blog.man7.org/2012/10/how-much-do-builtinexpect-likely-and.html
* http://stackoverflow.com/questions/109710/likely-unlikely-macros-in-the-linux-kernel-how-do-they-work-whats-their
* https://news.ycombinator.com/item?id=9411227