Tim Peters wrote: > [Fredrik Lundh] >> wouldn't be the first time... > > How soon we forget <wink>.
oh, that was in the dark ages of Python 1.4. I've rebooted myself many times since then... > Fredrik introduced a pile of optimizations special-casing the snot out > of small integers into ceval.c a long time ago iirc, you claimed that after a couple of major optimizations had been added, "there's no single optimization left that can speed up pystone by more than X%", so I came up with an "(X+2)%" optimization. you should do that more often ;-) > As a result, "i == j" in Python source code, when i and j are little > ints, is much faster than comparing i and j via any other route in > Python. which explains why my "in" vs. "or" tests showed good results for integers, but not for strings... I'd say that this explains why it would still make sense to let the code generator change "x in (a, b, c)" to "x == a or x == b or x == c", as long as a, b, and c are all integers. (see my earlier timeit results) </F> _______________________________________________ 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
