STINNER Victor added the comment:
Microbenchmark on Python 3.6, best of 3 runs:
./python -m timeit -r 11 -s "from collections import namedtuple as n; a =
n('n', 'a b c')(1, 2, 3)" -- "a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a;
a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a"
* Python 3.6 unpatched: 0.968 usec
* call_stack.patch: 1.27 usec
* Python 3.6 with property_descr_get() of Python 3.4: 1.32 usec
"Python 3.6 with property_descr_get() of Python 3.4": replace the current
optimization with "return PyObject_CallFunctionObjArgs(gs->prop_get, obj,
NULL);".
Oh, in fact the tested code calls a property where the final function is
operator.itemgetter(0). _PyObject_CallStack() creates a temporary tuple to call
PyObject_Call() which calls func->ob_type->tp_call, itemgetter_call().
Problem: tp_call API uses (PyObject *args, PyObject *kwargs). It doesn't accept
directly a stack (a C array of PyObject*). And it may be more difficult to
modify tp_call.
In short, my patch disables the optimization on property with my current
incomplete implementation.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue26814>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
