New submission from Antony Lee <[email protected]>:
Consider e.g.
In [2]: %timeit sorted([i for i in range(100)])
4.74 µs ± 24.3 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)
In [3]: %timeit sorted(i for i in range(100))
7.05 µs ± 25.7 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)
In [4]: %timeit sorted([i for i in range(1000)])
47.2 µs ± 1.2 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)
In [5]: %timeit sorted(i for i in range(1000))
78.7 µs ± 288 ns per loop (mean ± std. dev. of 7 runs, 10000 loops each)
In [6]: %timeit sorted([i for i in range(10000)])
582 µs ± 8.29 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)
In [7]: %timeit sorted(i for i in range(10000))
807 µs ± 5.92 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)
It appears that sorting a generator is slower than sorting the corresponding
list comprehension, by a ~constant factor. Given that the former can trivially
be converted into the latter (i.e. `sorted` could just check whether its
argument is a generator, and, if so, convert it to a list first), it would seem
that sorting the generator should *not* be slower than sorting a list (except
perhaps by a small constant).
----------
messages: 312780
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: sorted(generator) is slower than sorted(list-comprehension)
versions: Python 3.6
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue32945>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
