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 <rep...@bugs.python.org> <http://bugs.python.org/issue26814> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com