RetroSearch Browse

Tue Oct 11 10:24:59 EDT 2016 · https://mail.python.org/pipermail/python-dev/2016-October/146661.html

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.
Paul

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2016-October/146661.html below:

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