This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients Aaron Hall, benjamin.peterson, eric.snow, mark.dickinson, miss-islington, pablogsal, serhiy.storchaka, thatiparthy, vstinner
Date 2018-11-23.12:32:53
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Stefan Behnel wrote:

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.

I ran a benchmark on the compilation time using PR 10669: there is no significant slowdown (+4 seconds, 6% slower, in the worst case).

I ran a benchmark on my laptop:

* Fedora 29
* Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz: 4 physical cores (8 threads)
* GCC 8.2.1

Result in release mode:

* git clean -fdx; ./configure; time make # -03
* C macros: 1m12,158s
* static inline functions: 1m16,294s (+4.136s, +6%)

Result in debug mode:

* git clean -fdx; ./configure --with-pydebug; time make # -Og
* C macros: 0m39,727s
* static inline functions: 0m40,423s (+0.696s, +2%)

I only used "real" time (I ignored user and sys times).
Date User Action Args
2018-11-23 12:32:53vstinnersetrecipients: + vstinner, mark.dickinson, benjamin.peterson, eric.snow, serhiy.storchaka, thatiparthy, Aaron Hall, pablogsal, miss-islington
2018-11-23 12:32:53vstinnersetmessageid: <>
2018-11-23 12:32:53vstinnerlinkissue35059 messages
2018-11-23 12:32:53vstinnercreate