[Python-Dev] Re: Prospective Peephole Transformation

[Fredrik Lundh]

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>