[issue37774] Micro-optimize vectorcall using PY_LIKELY

[Jeroen Demeyer]

Jeroen Demeyer <jeroen.k.demeyer at gmail.com> added the comment:

> My question is if it is safe to let developers "abuse" it. If these macros are misused, they can lead to a performance regression.

I expect people using these macros and PR reviewers to use good judgement when to use these macros. There are many cases where the use of such macros should be uncontroversial, for example when checking for errors.

> For example, if you mark the error path as unlikely: this path will become slower. If the error path is taken "frequently" enough, the slowdown can become significant overall.

The speedup/slowdown that Py_LIKELY/Py_UNLIKELY gives is quite small, just a few clock cycles. This means that we shouldn't worry about performance regressions if the rest of the code takes much longer anyway. 

An example of this is raising exceptions, which typically involves PyErr_Format(). So I wouldn't worry too much about error paths getting slower.

> About the macros, I would prefer to make it private to not promote it.

I don't think it matters whether we call it Py_LIKELY or _Py_LIKELY. People that want to use it will use it anyway. And there is no issue with "provisional API" since this API is well-established in many existing projects.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37774>
_______________________________________