Message330316
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). |
|
Date |
User |
Action |
Args |
2018-11-23 12:32:53 | vstinner | set | recipients:
+ vstinner, mark.dickinson, benjamin.peterson, eric.snow, serhiy.storchaka, thatiparthy, Aaron Hall, pablogsal, miss-islington |
2018-11-23 12:32:53 | vstinner | set | messageid: <1542976373.57.0.788709270274.issue35059@psf.upfronthosting.co.za> |
2018-11-23 12:32:53 | vstinner | link | issue35059 messages |
2018-11-23 12:32:53 | vstinner | create | |
|