[Python-Dev] PEP 575 (Unifying function/method classes) update (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Tue Jun 19 08:02:35 EDT 2018


On 19 June 2018 at 16:12, INADA Naoki <songofacandy at gmail.com> wrote:

On Tue, Jun 19, 2018 at 2:56 PM Jeroen Demeyer <J.Demeyer at ugent.be> wrote:

On 2018-06-18 16:55, INADA Naoki wrote: > Speeding up most python function and some bultin functions was very > significant. > But I doubt making some 3rd party call 20% faster can make real > applications significant faster. These two sentences are almost contradictory. I find it strange to claim that a given optimization was "very significant" in specific cases while saying that the same optimization won't matter in other cases. It's not contradictory because there is basis: In most real world Python application, number of calling Python methods or bulitin functions are much more than other calls. For example, optimization for bulitin tpinit or tpnew by FASTCALL was rejected because it's implementation is complex and it's performance gain is not significant enough on macro benchmarks. And I doubt number of 3rd party calls are much more than calling builtin tpinit or tpnew.

I don't think this assumption is correct, as scientific Python software spends a lot of time calling other components in the scientific Python stack, and bypassing the core language runtime entirely.

However, they're using the CPython C API's function calling abstractions to do it, and those are currently expensive (frustratingly so, when the caller, the callee, and the interpreter implementation defining the call abstraction layer are all implemented in C). Hence Jeroen's PEPs to make the FASTCALL API a generally available one.

That's quite different from the situation with object constructors, where a whole lot of applications will get to the point of having a relatively stable working set of objects, and then see the rate of object creation slow down markedly.

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia



More information about the Python-Dev mailing list