[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