Gregory P. Smith schrieb am 15.11.18 um 01:03:
From my point of view: A static inline function is a much nicer modern code style than a C preprocessor macro.
It's also slower to compile, given that function inlining happens at a much later point in the compiler pipeline than macro expansion. The C compiler won't even get to see macros in fact, whereas whether to inline a function or not is a dedicated decision during the optimisation phase based on metrics collected in earlier stages. For something as ubiquitous as Py_INCREF/Py_DECREF, it might even be visible in the compilation times.
Oh, BTW, I don't know if this was mentioned in the discussion before, but transitive inlining can easily be impacted by the switch from a macro to an inline function. Since inlining happens long before the final CPU code generation, the C compiler needs to uses heuristics for estimating the eventual "code weight" of an inline function, and then sums up all weights within a calling function to decide whether to also inline that calling function into the transitive callers or not.
Now imagine that you have an inline function that executes several Py_INCREF/Py_DECREF call cycles, and the C compiler happens to slightly overestimate the weights of these two. Then it might end up deciding against inlining the function now, whereas it previously might have decided for it since it was able to see the exact source code expanded from the macros. I think that's what Raymond meant with his concerns regarding changing macros into inline functions. C compilers might be smart enough to always inline CPython's new inline functions themselves, but the style change can still have unexpected transitive impacts on code that uses them.
I agree with Raymond that as long as there is no clear gain in this code churn, we should not underestimate the risk of degarding code on user side.