[Python-Dev] Update on PEP 523 and adding a co_extra field to code objects (original) (raw)

Stefan Behnel stefan_ml at behnel.de
Wed Aug 31 02:59:00 EDT 2016

Nick Coghlan schrieb am 31.08.2016 um 06:30:

On 31 August 2016 at 04:55, Serhiy Storchaka wrote:

On 30.08.16 21:20, Antoine Pitrou wrote:

But the performance overhead of iterating over a 1-element list is small enough (it's just an array access after a pointer dereference) that it may not be larger than the overhead of the multiple tests and conditional branches your example shows.

Iterating over a tuple is even faster. It needs one pointer dereference less. That comes at the cost of making metadata additions a bit more complicated though - you'd have to replace the existing tuple with a new one that adds your own metadata, rather than just appending to a list. I do think there are enough subtleties here (going from no metadata -> some metadata, and some metadata -> more metadata) that it makes sense to provide a standard API for it (excluded from the stable ABI), rather than expecting plugin developers to roll their own. Strawman: PyObject * PyCodeGetExtra(PyCodeObject *code, PyTypeObject *extratype); int PyCodeSetExtra(PyCodeObject *code, PyObject *extra); int PyCodeDelExtra(PyCodeObject *code, PyTypeObject *extratype); Then Brett's example code would become: pyjioncache = PyCodeGetExtra(codeobj, &PyPyjionType); if (pyjioncache == NULL) { pyjioncache = PyPyjionNew(); if (PyCodeSetExtra(codeobj, pyjioncache) < 0) { /* Something went wrong, report that somehow */ } } /* pyjioncache is valid here */ Making those APIs fast (for an assumed small number of simultaneously active interpreter plugins) and thread-safe is then an internal CPython implementation detail, rather than being something plugin writers need to concern themselves with.

Looks like a good idea. New non-trivial field, new API.

GetExtra() can be a macro that implements the "only one entry and type pointer matches" case for speed, then call back into the list lookup for the less common cases.

Stefan

More information about the Python-Dev mailing list