[Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

[Nick Coghlan]

On 27 January 2018 at 07:35, Pau Freixes <pfreixes at gmail.com> wrote:

> This could be considered an unimportant thing, but its more relevant
> than someone could expect, at least IMHO. If the default code that you
> can write in a language is by default slow and exists an alternative
> to make it faster, this language is doing something wrong.
>

Not really, as we've seen with the relatively slow adoption of PyPy over
the past several years.

CPython, as an implementation, emphasises C/C++ compatibility, and internal
interpreter simplicity. That comes at a definite cost in runtime
performance (especially where attribute access and function calls are
concerned), but has also enabled an enormous orchestration ecosystem,
originally around C/C++/FORTRAN components, but now increasingly around
Rust components within the same process, as well as out-of-process Java,
C#, and JavaScript components. In this usage model, if Python code becomes
the throughput bottleneck, it's only because something has gone wrong at
the system architecture level.

PyPy, by contrast, emphasises raw speed, sacrificing various aspects of
CPython's C/C++ interoperability in order to attain it. It's absolutely the
implementation you want to be using if your main concern is the performance
of your Python code in general, and there aren't any obvious hotspots that
could be more selectively accelerated.

To date, the CPython model of "Use (C)Python to figure out what kind of
problem you have, then rewrite your performance bottlenecks in a language
more specifically tailored to that problem space" has proven relatively
popular. There's likely still more we can do within CPython to make typical
code faster without increasing the interpreter complexity too much (e.g.
Yury's idea of introducing an implicit per-opcode result cache into the
eval loop), but opt-in solutions that explicit give up some of Python's
language level dynamism are always going to be able to do less work at
runtime than typical Python code does.

Cheers,
Nick.

P.S. You may find
https://www.curiousefficiency.org/posts/2015/10/languages-to-improve-your-python.html#broadening-our-horizons
interesting in the context of considering some of the many factors other
than raw speed that may influence people's choice of programming language.
Similarly,
https://www.curiousefficiency.org/posts/2017/10/considering-pythons-target-audience.html
provides some additional info on the scope of Python's use cases (for the
vast majority of which, "How many requests per second can I serve in a
naive loop in a CPU bound process?" isn't a particularly relevant
characteristic)

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180127/2ec81f57/attachment.html>