On Jul 23, 2011, at 5:18 PM, Antoine Pitrou wrote:
>
> My point is that on non-trivial benchmarks, the savings are almost zero.
That could be said of any optimization in Python.
Typical Python scripts exercise many features at time,
so any one optimization by itself if almost useless.
Collective
I undrestand your point. Thank you for explanation.
On Sun, Jul 24, 2011 at 3:18 AM, Antoine Pitrou wrote:
> Le dimanche 24 juillet 2011 à 03:15 +0300, Andrew Svetlov a écrit :
>> You right. Sorry, I missed changes in ceval.c for py3k.
>> Please note, simple test like:
>>
>> from timeit import ti
Le dimanche 24 juillet 2011 à 03:15 +0300, Andrew Svetlov a écrit :
> You right. Sorry, I missed changes in ceval.c for py3k.
> Please note, simple test like:
>
> from timeit import timeit
>
> print('list', timeit("l[0]", "l = [1]"))
> print('tuple', timeit("l[0]", "l = (1,)"))
>
> Has results:
You right. Sorry, I missed changes in ceval.c for py3k.
Please note, simple test like:
from timeit import timeit
print('list', timeit("l[0]", "l = [1]"))
print('tuple', timeit("l[0]", "l = (1,)"))
Has results:
andrew@ocean ~/p/cpython> python2.7 z.py
('list', 0.03479599952697754)
('tuple', 0.04
On Sun, 24 Jul 2011 09:13:07 +1000
Ryan Kelly wrote:
>
> In latest trunk this optimisation seems to have gone away, the code is
> now:
>
> TARGET(BINARY_SUBSCR)
> w = POP();
> v = TOP();
> x = PyObject_GetItem(v, w);
> Py_DECREF(v);
>
On Sun, 2011-07-24 at 01:20 +0300, Andrew Svetlov wrote:
> tuple[int] is 30% slower than list[int].
> Please let me explain the problem.
>
> (1, 2, 3)[1] has compiled as BINARY_SUBSCR operation.
> ceval.c has optimization for list:
>
> case BINARY_SUBSCR:
> w = POP();
>
tuple[int] is 30% slower than list[int].
Please let me explain the problem.
(1, 2, 3)[1] has compiled as BINARY_SUBSCR operation.
ceval.c has optimization for list:
case BINARY_SUBSCR:
w = POP();
v = TOP();
if (PyList_CheckExact(v) && PyInt_CheckExact(w
