带有连接功能的列表vs生成器理解速度[重复]

Question

这个问题已经在这里有了答案 ：

列表理解与生成器表达式的奇怪时间结果？ （3个答案）

在Python中不带[]的列表理解 （7个答案）

4年前关闭。

因此，我从官方文档中获得了这些示例。
https://docs.python.org/2/library/timeit.html

是什么使第一个示例（生成器表达式）比第二个示例（列表理解）更慢？

>>> timeit.timeit('"-".join(str(n) for n in range(100))', number=10000)
0.8187260627746582
>>> timeit.timeit('"-".join([str(n) for n in range(100)])', number=10000)
0.7288308143615723

Answer 1

如果该str.join方法不是列表或元组，则将其可迭代参数转换为列表。这样，联接逻辑就可以对项目进行多次迭代（通过一次传递来计算结果字符串的大小，然后进行第二次传递以实际复制数据）。

您可以在CPython源代码中看到这一点：

PyObject *
PyUnicode_Join(PyObject *separator, PyObject *seq)
{
    /* lots of variable declarations at the start of the function omitted */

    fseq = PySequence_Fast(seq, "can only join an iterable");

    /* ... */
}

PySequence_FastC
API中的功能正是我所描述的。它将一个任意的Iterable转换为一个列表（基本上是通过调用list它），除非它已经是一个列表或元组。

将生成器表达式转换为列表意味着生成器的通常好处（较小的内存占用量和发生短路的可能性）不适用于str.join，因此生成器具有的（较小）额外开销使性能得以提高。更差。