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 <1542976373.57.0.788709270274.issue35059@psf.upfronthosting.co.za>
In-reply-to
Content
Stefan Behnel wrote:
https://mail.python.org/pipermail/python-dev/2018-November/155759.html

"""
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
* MAKEFLAGS=-j9

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).
History
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: <1542976373.57.0.788709270274.issue35059@psf.upfronthosting.co.za>
2018-11-23 12:32:53vstinnerlinkissue35059 messages
2018-11-23 12:32:53vstinnercreate