[MvL]
OTOH, this same code caused a 10% slowdown if I converted the "==" into "<>".
[MAL]
This sounds like an alignment problem caused by the compiler. 10% speedups/slowdowns can easily be produced by randomly moving about a few cases in the ceval loop. All depends on the platform and compiler though.
I expect a more obvious cause is at work: every one of Martin's "<>" compares was slowed by the new batch of failing "is it an EQ and are these strings and are they identical?" tests and branches. Fast paths lose when when they don't win -- they aren't neutral then. Indeed, we could speed your particular app by getting rid of the int-compare fast path already there (but I expect that one is a *net* win across apps, so don't want to get rid of it <wink>).
Running the PyXML test suite, I counted 120000 cases where slow_compare was done, and only 700 cases identical strings were compared for equality.
As Fred mentioned, this is probably due to the fact that Unicode objects are not interned. Neither are typical XML tag names; could make a difference... don't know.
Whatever it's due to, it means the fast-path code cost extra cycles in the 119300 (of 120000) cases it didn't pay off. If it costs F extra cycles when it fails, and saves S cycles when it succeeds, the question for this test is whether 119300*F < 700*S. S has to about about 170X larger than F for a net win in this case, else there's a net loss.