j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
-----Original Message----- From: Python-Dev [mailto:python-dev- firstname.lastname@example.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.