<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Mar 9, 2017 at 3:04 AM Barry Scott <<a href="mailto:barry@barrys-emacs.org">barry@barrys-emacs.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">So you do O(nlogn)*2 pointer compares with my suggestion it seems? Which is smaller the O(n) pointer checks?</div></div></div></blockquote><div><br></div><div>Not sure what you mean here... pretty sure your inequality is backwards?<br><br></div><div>Look -- the point is, we already *do* the pointer checks during every compare. That's the current implementation. I believe my benchmarks are sufficient to prove that my patch is much faster than the current implementation. Which makes sense, because we do one type check per object, as opposed to something like log n per object, and we do them all at once, which I do believe is faster than doing them across calls.<br><br></div><div>Now, you're not entirely wrong -- the current implementation doesn't do the type checks as efficiently as it could. Specifically, it does them once in PyObject_RichCompareBool, and then *again* in ob_type->tp_richcompare (which it has to for safety: ob_type->tp_richcompare doesn't know the arguments have already been type-checked!) You could totally define optimized compares that do the type-checks more efficiently, and you would see a benefit, just not nearly as extreme as the benefit I demonstrate.<br><br></div><div>Thanks again for your feedback!<br></div><div>Elliot<br></div></div></div>