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

[Nick Coghlan]

On 31 August 2016 at 04:55, Serhiy Storchaka <storchaka at gmail.com> 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 * PyCode_GetExtra(PyCodeObject *code, PyTypeObject *extra_type);
    int PyCode_SetExtra(PyCodeObject *code, PyObject *extra);
    int PyCode_DelExtra(PyCodeObject *code, PyTypeObject *extra_type);

Then Brett's example code would become:

    pyjion_cache = PyCode_GetExtra(code_obj, &PyPyjion_Type);
    if (pyjion_cache == NULL) {
        pyjion_cache = PyPyjion_New();
        if (PyCode_SetExtra(code_obj, pyjion_cache) < 0) {
            /* Something went wrong, report that somehow */        }
    }
    /* pyjion_cache 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.

Cheers,
Nick.

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