On Sun, 18 Nov 2018 13:53:54 -0800 Nathaniel Smith <n...@pobox.com> wrote: > On Sun, Nov 18, 2018 at 8:52 AM Stefan Behnel <stefan...@behnel.de> wrote: > > > > Gregory P. Smith schrieb am 15.11.18 um 01:03: > > > From my point of view: A static inline function is a much nicer modern > > > code > > > style than a C preprocessor macro. > > > > 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. > > Have you measured this? I had the opposite intuition, that macros on > average will be slower to compile because they increase the amount of > code that the frontend has to process. But I've never checked...
It will certainly depend on how much code the macro expands to. Py_INCREF is an extremely simple macro, so expanding everywhere doesn't sound like a problem. On the other hand, modern "macros" that are C++ templates can inline vast amounts of code at the call site, and that's a common cause of slow C++ compiles. Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
