Phillip J. Eby wrote:
>>Only contains expressions are translated:
>>
>> "if x in [1,2,3]"
>>
>>currently turns into:
>>
>> "if x in (1,2,3)"
>>
>>and I'm proposing that it go one step further:
>>
>> "if x in Seachset([1,2,3])"
>
> ISTM that whenever I use a constant in-list like that, it's almost always with just a few (<4)
> items, so it doesn't seem worth the extra effort (especially disrupting the marshal module) just
> to squeeze out those extra two comparisons and replace them with a hashing operation.
it could be worth expanding them to
"if x == 1 or x == 2 or x == 3:"
though...
C:\>timeit -s "a = 1" "if a in (1, 2, 3): pass" 10000000 loops, best of 3: 0.11 usec per loop C:\>timeit -s "a = 1" "if a == 1 or a == 2 or a == 3: pass" 10000000 loops, best of 3: 0.0691 usec per loop
C:\>timeit -s "a = 2" "if a == 1 or a == 2 or a == 3: pass" 10000000 loops, best of 3: 0.123 usec per loop C:\>timeit -s "a = 2" "if a in (1, 2, 3): pass" 10000000 loops, best of 3: 0.143 usec per loop
C:\>timeit -s "a = 3" "if a == 1 or a == 2 or a == 3: pass" 10000000 loops, best of 3: 0.187 usec per loop C:\>timeit -s "a = 3" "if a in (1, 2, 3): pass" 1000000 loops, best of 3: 0.197 usec per loop
C:\>timeit -s "a = 4" "if a in (1, 2, 3): pass" 1000000 loops, best of 3: 0.225 usec per loop C:\>timeit -s "a = 4" "if a == 1 or a == 2 or a == 3: pass" 10000000 loops, best of 3: 0.161 usec per loop
</F>
Were these timings done with the code that turns (1,2,3) into a constant?
Also, I presume that these timings still include extra LOAD_FAST operations that could be replaced with DUP_TOP in the actual expansion, although I don't know how much difference that would make in practice, since saving the argument fetch might be offset by the need to swap and pop at the end.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com