git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] General concerns about C API changes


On Sun, 18 Nov 2018 13:53:54 -0800
Nathaniel Smith <njs at pobox.com> wrote:
> On Sun, Nov 18, 2018 at 8:52 AM Stefan Behnel <stefan_ml at 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.