[Python-Dev] PEP 575 (Unifying function/method classes) update
songofacandy at gmail.com
Tue Jun 19 09:36:34 EDT 2018
That's why I suggested to add new benchmark.
2018年6月19日(火) 22:22 Ivan Levkivskyi <levkivskyi at gmail.com>:
> On 19 June 2018 at 13:02, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> 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>
>> >> 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
>> >> that a given optimization was "very significant" in specific cases
>> >> 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
>> > 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
> A recent Python survey by PSF/JetBrains shows that almost half of current
> users are using it for data science/ML/etc. For all these people most of
> the time is spent
> on calling C functions in extensions.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev