[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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4