[Python-Dev] Micro-benchmarks for PEP 580

[Nick Coghlan]

On 11 July 2018 at 18:50, Victor Stinner <vstinner at redhat.com> wrote:
> I'm skeptical about "50% gain": I want to see a working implementation
> and reproduce benchmarks myself to believe that :-) As you wrote, the
> cost of function costs is unlikely the bottleneck of application.
>
> Sorry, I didn't read all these PEPs about function calls, but IMHO a
> minor speedup on micro benchmarks must not drive a PEP. If someone
> wants to work on CPython performance, I would suggest to think bigger
> and target 2x speedup on applications. To get to this point, the
> bottleneck is the C API and so we have to fix our C API first.

Folks, I'd advise against focusing too heavily on CPython performance
when reviewing PEP 580, as PEP 580 is *not primarily about CPython
performance*. The key optimisations it enables have already been
implemented in the form of FASTCALL, so nothing it does is going to
make CPython faster.

Instead, we're being approached in our role as the *central standards
management group for the Python ecosystem*, similar to the way we were
involved in the establishment of PEP 3118 as the conventional
mechanism for zero-copy data sharing. While Stefan Krah eventually
brought memoryview up to speed as a first class PEP 3118 buffer
exporter and consumer, adding the memoryview builtin wasn't the
*point* of that PEP - the point of the PEP was to let libraries like
NumPy and PIL share the same backing memory across different Python
objects without needing to know about each other directly.

The request being made is a similar case of ecosystem enablement -
it's less about the performance of any specific case (although that's
certainly a significant intended benefit), and more about providing
participants in the Python ecosystem more freedom to architect their
projects in the way that makes the most sense from an ongoing
maintenance perspective, without there being a concrete and measurable
performance *penalty* in breaking a large monolithic extension module
up into smaller independently updatable components.

Cheers,
Nick.

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