Phillip J. Eby wrote:
> Were these timings done with the code that turns (1,2,3) into a constant?
I used a stock 2.4 from python.org, which seems to do this (for tuples, not for lists).
> 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.
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. But whatever.
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?
_______________________________________________ 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
