[Python-ideas] Submitted a PR!

[Elliot Gorokhovsky]

There is an "apple to apple" compare function. It's unsafe_object_compare.
If you look at the pre-sort check, you will find that if the list is
homogeneous but not of float, int, string, or tuple, it sets
compare_funcs.key_richcompare = ob_type->tp_richcompare and sets
compare_funcs.key_compare = unsafe_object_compare. The latter is a wrapper
for the former, bypassing the type checks in PyObject_RichCompareBool.
Examples of benchmarks that use this functionality include the non-latin
string and unbounded int benchmarks.

In the table at the bottom of my patch description, it's described as
follows:

Compare function for general homogeneous lists; just a wrapper for
ob_type->tp_richcompare, which is stored by the pre-sort check at
compare_funcs.key_richcompare. This yields modest optimization
(neighbourhood of 10%), but we generally hope we can do better.

Further, in the code, the comments describe it as follows:

/* Homogeneous compare: safe for any two compareable objects of the same
type.
* (compare_funcs.key_richcompare is set to ob_type->tp_richcompare in the
* pre-sort check.)
*/

Does that answer your question?



On Thu, Mar 9, 2017 at 6:18 PM Erik <python at lucidity.plus.com> wrote:

> Hi.
>
> I may be way off-base here, but having scanned the patch I'm not sure I
> agree that it's the right way forward.
>
> What seems to be happening is that the homogeneity of the list is
> determined somehow (whether tracked with a hint or scanned just-in-time)
> and then a specific comparison function for a known subset of built-in
> types is selected if appropriate.
>
> I had assumed that there would be an "apples-to-apples" comparison
> function in the type structure and that the patch was simply tracking
> the list's homogeneity in order to enter a (generic) alternative loop to
> call that function over PyObject_RichCompare().
>
> Why is that not the case? When a new C-level type is introduced (either
> a built-in or an extension module), why does the list object's code need
> to know about it in order to perform this optimisation?
>
> Why is there not a "tp_apple2apple" slot in the type structure which
> higher level functions (including the RichCompare() stuff - the first
> thing that function does is check the type of the objects anyway) can
> call if it determines that the two objects have the same type?
>
> Such a slot would also speed up "contains", "count", etc (for all
> classes) with no extra work, and no overhead of tracking or scanning the
> sequence's homogeneity.
>
> E.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170310/0d6a1145/attachment.html>