[Python-Dev] Micro-benchmarks for PEP 580 (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Wed Jul 11 08:56:57 EDT 2018

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

More information about the Python-Dev mailing list