STINNER Victor <vstin...@redhat.com> added the comment:
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). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue35059> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
