[Python-Dev] Optimizing list.sort() by checking type in advance

Chris Angelico rosuav at gmail.com
Tue Oct 11 10:26:00 EDT 2016


On Wed, Oct 12, 2016 at 1:24 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 11 October 2016 at 15:00, Chris Angelico <rosuav at gmail.com> wrote:
>> On Wed, Oct 12, 2016 at 12:51 AM, Paul Moore <p.f.moore at gmail.com> wrote:
>>> On 11 October 2016 at 14:04, Elliot Gorokhovsky
>>> <elliot.gorokhovsky at gmail.com> wrote:
>>>> Right, that sounds good, but there's just one thing I don't understand
>>>> that's keeping me from using it. Namely, I would define a benchmark list L
>>>> in my setup, and then I would have code="F=FastList(L);F.fastsort()". The
>>>> problem here is I'm measuring the constructor time along with the sort time,
>>>> right, so wouldn't that mess up the benchmark? Or does timeit separate the
>>>> times?
>>>
>>> That would mess up your times. Put F=FastList(L) in your setup.
>>
>> But then you're resorting an already-sorted list, which may well have
>> different timings (it certainly does in timsort).
>
> Why would it be already sorted? I assume FastList(L) is simply a
> wrapper round a normal list that has a modified sort method with the
> optimisation included.
>
> Of course, that's essentially the point here - without seeing the
> code, we're (to an extent) guessing.

After the first call, the list will be sorted. Any subsequent attempts
will use the sorted list.

ChrisA


More information about the Python-Dev mailing list