python 列表推导 为什么快_python – 列表推导和函数函数比“for循环”快？

以下是基于经验的粗略准则和有根据的猜测。你应该对你的具体用例进行计时或分析，以获取硬数字，这些数字有时可能不同意以下。

列表解析通常比精确等价的for循环(实际构建列表)快一点，很可能是因为它不需要在每次迭代时查找列表及其append方法。然而，列表解析仍然执行字节码级循环：

>>> dis.dis()

1 0 BUILD_LIST 0

3 LOAD_FAST 0 (.0)

>> 6 FOR_ITER 12 (to 21)

9 STORE_FAST 1 (x)

12 LOAD_FAST 1 (x)

15 LIST_APPEND 2

18 JUMP_ABSOLUTE 6

>> 21 RETURN_VALUE

使用列表解析代替不构建列表的循环，无意义地累积无意义值的列表，然后将列表离开，通常较慢，因为创建和扩展列表的开销。列表推导不是魔法，本质上比一个好的老循环更快。

至于功能列表处理功能：虽然这些是用C编写的，并且可能优于用Python编写的等效函数，但它们不一定是最快的选项。如果函数以C语言编写，则预期会有一些加速。但是大多数情况下使用lambda(或其他Python函数)，重复设置Python堆栈帧等的开销，可以节省任何费用。简单地在线执行相同的工作，没有函数调用(例如列表解析而不是地图或过滤器)通常稍快。

Suppose that in a game that I’m developing I need to draw complex and huge maps using for loops. This question would be definitely relevant, for if a list-comprehension, for example, is indeed faster, it would be a much better option in order to avoid lags (Despite the visual complexity of the code).

有机会是，如果这样的代码还不够快，当写在良好的非“优化”的Python，没有量的Python级微优化将使它足够快，你应该开始考虑放弃C.虽然广泛微优化通常可以加快Python代码的速度，有一个很低的(绝对条件)的限制。此外，即使在你达到上限之前，它也变得更加节省成本(15％的加速，而300％的加速与同样的努力)咬住子弹和写一些C.