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