On 11 July 2018 at 18:50, Victor Stinner <vstin...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
