Author haypo
Recipients haypo, larry, rhettinger, serhiy.storchaka, yselivanov
Date 2016-04-21.10:20:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1461234050.77.0.00621555347861.issue26814@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2016-04-21 10:20:50hayposetrecipients: + haypo, rhettinger, larry, serhiy.storchaka, yselivanov
2016-04-21 10:20:50hayposetmessageid: <1461234050.77.0.00621555347861.issue26814@psf.upfronthosting.co.za>
2016-04-21 10:20:50haypolinkissue26814 messages
2016-04-21 10:20:50haypocreate