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

Nick Coghlan ncoghlan at gmail.com
Sun Jan 28 06:09:07 EST 2018


On 28 January 2018 at 17:35, Pau Freixes <pfreixes at gmail.com> wrote:
>> At a technical level, the biggest problems relate to the way we
>> manipulate frame objects at runtime, including the fact that we expose
>> those frames programmatically for the benefit of debuggers and other
>> tools.
>
> Shoudnt be something that could be tackled with the introduction of a
> kind of "-g" flag ? Asking the user to make explicit that is willing
> on having all of this extra information that in normal situations
> won't be there.

This is exactly what some other Python runtimes do, although some of
them are also able to be clever about it and detect at runtime if
you're doing something that relies on access to frame objects (e.g.
PyPy does that).

That's one of the biggest advantages of making folks opt-in to code
acceleration measures, whether it's using a different interpreter
implementation (like PyPy), or using some form of accelerator in
combination with CPython (like Cython or Numba): because those tools
are opt-in, they don't necessarily need to execute 100% of the
software that runs on CPython, they only need to execute the more
speed sensitive software that folks actually try to run on them.

And because they're not directly integrated into CPython, they don't
need to abide by our design and implementation constraints either.

Cheers,
Nick.

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


More information about the Python-ideas mailing list