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

Ivan Levkivskyi levkivskyi at gmail.com
Tue Jun 19 09:22:50 EDT 2018

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> 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. A recent Python survey by PSF/JetBrains shows that almost half of current Python 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.

-- Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20180619/94c4d470/attachment-0001.html>

More information about the Python-Dev mailing list