[Python-Dev] heapq, min and max
python at rcn.com
Wed Oct 22 22:51:40 CEST 2008
I think this should be taken off of python-dev until
you have some quality measurements,
know what's going on, and have an actionable idea.
Aside from list specialization versus a general iterator
protocol, there is no fat in the min/max implementation.
It loops, it compares, it returns.
If we wanted to go the distance and type specialize,
it is possible to use the same ideas that used in
Py2.6's builtin sum() to speed-up compares for particular types.
Personally, I think that would be a waste and would rather
keep the code simple.
Also, a primary use case for min/max is with just two inputs.
We don't want to slow that down in order to provide negligible
improvements to min/max for long sequences.
----- Original Message -----
From: "Kristján Valur Jónsson" <kristjan at ccpgames.com>
To: "Antoine Pitrou" <solipsis at pitrou.net>; <python-dev at python.org>
Sent: Wednesday, October 22, 2008 1:37 PM
Subject: Re: [Python-Dev] heapq, min and max
> Kt just occurred to me:
> Even though l.sort() is sorting a presorted array, it still must be doing
> 10000-1 RichCompares minimum, just like max. So how do we explain the
> large difference?
>> -----Original Message-----
>> From: python-dev-bounces+kristjan=ccpgames.com at python.org
>> [mailto:python-dev-bounces+kristjan=ccpgames.com at python.org] On Behalf
>> Of Antoine Pitrou
>> Sent: Wednesday, October 22, 2008 14:06
>> To: python-dev at python.org
>> Subject: Re: [Python-Dev] heapq, min and max
>> Kristján Valur Jónsson <kristjan <at> ccpgames.com> writes:
>> > timeit.Timer("(l.sort(), l[-1])",
>> > s).timeit(1000)
>> > 0.29406761513791935
>> This is clearly wrong. l.sort() will sort the list in place when it is
>> invoked, and therefore will be very fast in subsequent calls.
> Python-Dev mailing list
> Python-Dev at python.org
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/python%40rcn.com
More information about the Python-Dev