以下是粗略的准则和基于经验的有根据的猜测。你应该timeit或配置你的具体用例以获得确切的数字，并且这些数字有时可能与以下内容不一致。

列表理解通常比精确等效的for循环（实际上是构建列表）要快一点，这很可能是因为它不必append在每次迭代时都查找列表及其方法。但是，列表理解仍然会执行字节码级别的循环：

>>> dis.dis(<the code object for `[x for x in range(10)]`>)
 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堆栈框架等开销会消耗掉所有的节省。在没有函数调用的情况下，简单地在线完成相同的工作（例如，用列表理解代替mapor filter）通常会稍快一些。

假设在我正在开发的游戏中，我需要使用for循环绘制复杂而庞大的地图。这个问题绝对是相关的，例如，如果列表理解确实确实更快，那么它将是避免滞后的更好选择（尽管代码具有视觉复杂性）。

很有可能，如果用良好的非“优化” Python编写时这样的代码还不够快，那么就没有足够的Python级别的微优化会使其变得足够快，因此你应该开始考虑使用C语言。微观优化通常可以大大加快Python代码的速度，对此（绝对值）的限制很低。而且，即使在达到极限之前，咬住子弹并写一些C语言也变得更具成本效益（加速15％，加速300％）。