Message330316
| 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). |
|