At 05:52 PM 2/18/05 +0100, Fredrik Lundh wrote: >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?
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4