列表理解和函数功能是否比“for循环”更快？

Question

就Python的性能而言，是列表理解，还是map（）、filter（）和duce（）等函数比for循环更快？为什么从技术上讲，它们以C速度运行，而for循环以python虚拟机速度运行？

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

Answer 1

您特别询问了map（）、filter（）和duce（），但我假设您想了解一般的函数式编程。在自己就计算一组点内所有点之间的距离问题进行了测试后，函数式编程（使用内置itertools模块中的starmap函数）结果比for循环稍慢（实际上需要1.25倍的时间）。这是我使用的示例代码：

import itertools, time, math, random

class Point:
    def __init__(self,x,y):
        self.x, self.y = x, y

point_set = (Point(0, 0), Point(0, 1), Point(0, 2), Point(0, 3))
n_points = 100
pick_val = lambda : 10 * random.random() - 5
large_set = [Point(pick_val(), pick_val()) for _ in range(n_points)]
    # the distance function
f_dist = lambda x0, x1, y0, y1: math.sqrt((x0 - x1) ** 2 + (y0 - y1) ** 2)
    # go through each point, get its distance from all remaining points 
f_pos = lambda p1, p2: (p1.x, p2.x, p1.y, p2.y)

extract_dists = lambda x: itertools.starmap(f_dist, 
                          itertools.starmap(f_pos, 
                          itertools.combinations(x, 2)))

print('Distances:', list(extract_dists(point_set)))

t0_f = time.time()
list(extract_dists(large_set))
dt_f = time.time() - t0_f

功能版比程序版快吗？

def extract_dists_procedural(pts):
    n_pts = len(pts)
    l = []    
    for k_p1 in range(n_pts - 1):
        for k_p2 in range(k_p1, n_pts):
            l.append((pts[k_p1].x - pts[k_p2].x) ** 2 +
                     (pts[k_p1].y - pts[k_p2].y) ** 2)
    return l

t0_p = time.time()
list(extract_dists_procedural(large_set)) 
    # using list() on the assumption that
    # it eats up as much time as in the functional version

dt_p = time.time() - t0_p

f_vs_p = dt_p / dt_f
if f_vs_p >= 1.0:
    print('Time benefit of functional progamming:', f_vs_p, 
          'times as fast for', n_points, 'points')
else:
    print('Time penalty of functional programming:', 1 / f_vs_p, 
          'times as slow for', n_points, 'points')

Answer 2

如果你查看python上的信息。org，您可以看到以下摘要：

Version Time (seconds)
Basic loop 3.47
Eliminate dots 2.45
Local variable & no dots 1.79
Using map function 0.54

但您确实应该详细阅读上述文章，以了解性能差异的原因。

我还强烈建议您应该使用timeit为代码计时。在一天结束时，可能会出现这样一种情况，例如，当满足条件时，您可能需要跳出for循环。它可能比通过调用map来找出结果更快。

Answer 3

以下是基于经验的粗略指导和有根据的猜测。你应该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堆栈框架等的开销会消耗掉任何节省。简单地在线执行相同的工作，而不需要函数调用（例如，列表理解而不是map或filter）通常会稍微快一点。

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

很有可能，如果这样的代码在用好的非“优化”Python编写时还不够快，那么无论多少Python级别的微优化都无法使其足够快，您应该开始考虑降为C。虽然广泛的微优化通常可以显着加快Python代码的速度，但这种情况的限制很低（绝对而言）。此外，即使在您达到上限之前，咬紧牙关编写一些C也会变得更具成本效益（15%的加速比与300%的加速）。