[Python-Dev] Re: Re: Re: Prospective Peephole Transformation

[Tim Peters]

[Phillip J. Eby]
>> 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?

[Fredrik Lundh]
> wouldn't be the first time...

How soon we forget <wink>.  Fredrik introduced a pile of optimizations
special-casing the snot out of small integers into ceval.c a long time
ago, like this in COMPARE_OP:

case COMPARE_OP:
	w = POP();
	v = TOP();
	if (PyInt_CheckExact(w) && PyInt_CheckExact(v)) {
		/* INLINE: cmp(int, int) */
		register long a, b;
		register int res;
		a = PyInt_AS_LONG(v);
		b = PyInt_AS_LONG(w);
		switch (oparg) {
		case PyCmp_LT: res = a <  b; break;
		case PyCmp_LE: res = a <= b; break;
		case PyCmp_EQ: res = a == b; break;
		case PyCmp_NE: res = a != b; break;
		case PyCmp_GT: res = a >  b; break;
		case PyCmp_GE: res = a >= b; break;
		case PyCmp_IS: res = v == w; break;
		case PyCmp_IS_NOT: res = v != w; break;
		default: goto slow_compare;
		}
		x = res ? Py_True : Py_False;
		Py_INCREF(x);
	}
	else {
		  slow_compare:
			x = cmp_outcome(oparg, v, w);
	}

That's a hell of a lot faster than tuple comparison's deferral to
PyObject_RichCompareBool can be, even if we inlined the same blob
inside the latter (then we'd still have the additional overhead of
calling PyObject_RichCompareBool).  As-is, PyObject_RichCompareBool()
has to do (relatively) significant work just to out find which
concrete comparision implementation to call.

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.  That's mostly really good, IMO -- /F's int optimizations are
of major value in real life.  Context-dependent optimizations make
code performance less predictable too -- that's life.