[Python-Dev] Comparison speed

[Tim Peters]

[Martin v. Loewis]
> I'll put a patch on SF soon which does what you want to do, i.e. tries
> tp_compare as the first thing if tp_richcompare is not there.

Thanks!  I'll check it out.

> Even with this patch, your code is faster if strings have a
> richcompare.

OK, from what I understand, that makes no sense.  Does it to you?  Assuming
you're still talking about my silly little

     "ab" < "cd"

test, then all the new code you put into your richcompare slot was a waste of
cycles for that specific case:  the new richcmp "objects the same type?" test
would fail, then the new "pointers equal?" test would fail, then the new "op
== Py_EQ?" test would fail, and then richcompare would give up and call
string_compare() anyway.  So I'm either missing something fundamental about
what you did, or it's a timing anomaly on your box that defies obvious
explanation ("but if I add three new tests that don't pay off, and make an
extra call, then it's faster!").

> Without richcompare, I get
>
> 0.720
> 0.720
> 0.720
> 0.730
> 0.720
> 0.720
> 0.730
> 0.720
> 0.720
> 0.730
>
> With it, I get
>
> 0.710
> 0.720
> 0.720
> 0.710
> 0.710
> 0.720
> 0.710
> 0.710
> 0.710
> 0.720

See above.

> Given that stock CVS python is in the 0.78 range, the different is
> neglectable, though.

Oh, I don't like giving up that easy on things that make no sense --
something else is happening here, although I've no idea what.