[Python-ideas] a sorting protocol dunder method?
rosuav at gmail.com
Mon Dec 4 16:55:16 EST 2017
On Tue, Dec 5, 2017 at 8:22 AM, Barry <barry at barrys-emacs.org> wrote:
>> On 4 Dec 2017, at 20:12, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> On Mon, 4 Dec 2017 19:37:02 +0000
>> Barry Scott <barry at barrys-emacs.org> wrote:
>>> I wondered what the performance would be and tested the following code:
>>> it outputs this for my with python 3.6.0
>>> key 0.010628s 10000 calls
>>> lt 0.053690s 119886 calls
>>> It seems that providing a key is ~5 times faster the depending on __lt__.
>>> (I even used a short circuit to se if __lt__ could beat key).
>> Thanks for taking the time to write a benchmark. I'm not surprised
>> by the results (and your __lt__ method isn't even complicated: the gap
>> could be very much wider). There is more to Python performance than
>> aggregate big-O algorithmic complexity.
> I was surprised by the huge difference. I was expecting a closer race.
> For the record I think that a __sort_key__ is not a good idea as it is so easy to
> do as I did and define key methods on the class, without the limit of one such
The numbers here are all fairly small, but they make a lot of sense.
Calls into Python code are potentially quite slow, so there's a LOT of
benefit to be had by calling Python code once per object instead of N
log N times for the comparisons. Increasing the length of the list
will make that difference even more pronounced.
But that's an argument for using a key function, not for having a
__key__ special method.
More information about the Python-ideas