[Python-Dev] PEP 575 (Unifying function/method classes) update
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 `tp_init` or `tp_new` 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
> tp_init or tp_new.
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