[Python-Dev] Slices and "==" optimization

[Tim Peters]

[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.