[Python-Dev] Re: Re: Re: Prospective Peephole Transformation
Fredrik Lundh
fredrik at pythonware.com
Fri Feb 18 18:12:50 CET 2005
Phillip J. Eby wrote:
>>here's the disassembly:
>
> FYI, that's not a dissassembly of what timeit was actually timing; see 'template' in timeit.py.
> As a practical matter, the only difference would probably be the use of LOAD_FAST instead of
> LOAD_NAME, as
> timeit runs the code in a function body.
>>> def f1(a):
... if a in (1, 2, 3):
... pass
...
>>> def f2(a):
... if a == 1 or a == 2 or a == 3:
... pass
...
>>> dis.dis(f1)
2 0 LOAD_FAST 0 (a)
3 LOAD_CONST 4 ((1, 2, 3))
6 COMPARE_OP 6 (in)
9 JUMP_IF_FALSE 4 (to 16)
12 POP_TOP
3 13 JUMP_FORWARD 1 (to 17)
>> 16 POP_TOP
>> 17 LOAD_CONST 0 (None)
20 RETURN_VALUE
>>>
>>> dis.dis(f2)
2 0 LOAD_FAST 0 (a)
3 LOAD_CONST 1 (1)
6 COMPARE_OP 2 (==)
9 JUMP_IF_TRUE 26 (to 38)
12 POP_TOP
13 LOAD_FAST 0 (a)
16 LOAD_CONST 2 (2)
19 COMPARE_OP 2 (==)
22 JUMP_IF_TRUE 13 (to 38)
25 POP_TOP
26 LOAD_FAST 0 (a)
29 LOAD_CONST 3 (3)
32 COMPARE_OP 2 (==)
35 JUMP_IF_FALSE 4 (to 42)
>> 38 POP_TOP
3 39 JUMP_FORWARD 1 (to 43)
>> 42 POP_TOP
>> 43 LOAD_CONST 0 (None)
46 RETURN_VALUE
> Still, it's rather interesting that tuple.__contains__ appears slower than a series of LOAD_CONST
> and "==" operations, considering that the tuple should be doing basically the same thing, only
> without bytecode fetch-and-decode overhead. Maybe it's tuple.__contains__ that needs optimizing
> here?
wouldn't be the first time...
</F>
More information about the Python-Dev
mailing list