以下是粗略的准则和基于经验的有根据的猜测。你应该timeit或配置你的具体用例以获得确切的数字，并且这些数字有时可能与以下内容不一致。
列表理解通常比精确等效的
for循环（实际上是构建列表）要快一点，这很可能是因为它不必append在每次迭代时都查找列表及其方法。但是，列表理解仍然会执行字节码级别的循环：
>>> dis.dis(<the pre object for `[x for x in range(10)]`>) 10 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％）。
