On 31 August 2016 at 04:55, Serhiy Storchaka <[email protected]> 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 | [email protected] | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com