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

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