[Python-Dev] Start writing inlines rather than macros?

Kristján Valur Jónsson kristjan at ccpgames.com
Fri Feb 28 10:47:07 CET 2014



> -----Original Message-----
> From: Python-Dev [mailto:python-dev-
> bounces+kristjan=ccpgames.com at python.org] On Behalf Of Skip Montanaro
> Sent: 27. febrúar 2014 19:12
> To: python-dev Dev
> Subject: Re: [Python-Dev] Start writing inlines rather than macros?
> one question though. Suppose you encounter a compiler that
> doesn't understand the inline keyword, so you choose the static declaration
> as Kristján suggested. The resulting Python executable should be functionally
> correct, but if the optimizer doesn't happen to inline a given static function
> you might be stuck with some bad performance across-the-board (if it never
> inlines, or doesn't inline where we really need it to), or only under some
> circumstances (as a hypothetical example, inlining in dictobject.c, but not in
> ceval.c).
> Is there a configurable way to tell if a compiler will inline functions which are
> declared static, and possibly under what conditions they might not? It might
> still be necessary to maintain macros for those platforms.

It would be horrible to have to maintain both macros and functions.
My suggestion would be to use functions for new code, and new use cases.
We would stick with Py_INCREF() , and continue using that in obvious cases, (such
as in the implementation of the new functions)
but at the same time introduce a Py_IncRef() function returning a new reference,
which can be used in new code where it is convenient.

The new macros under discussion, Py_INCREF_AND_REPLACE_WITH_GUSTO() and
all of them would then be redesigned in a more composable functional form.

This way, only new code would be compiled with different efficiency on different
platforms, thus avoiding introducing performance regressions.

K


More information about the Python-Dev mailing list