列表理解绩效评价后效率的混淆

Question

今天，我对列表理解和filter()函数进行了一些实验，因为我感兴趣的是，如果使用一种而另一种，是否有显着的效率改进。结果有点混乱。当我筛选偶数时，列表理解比传统的嵌套结构和filter()函数的性能高出大约1.5倍(也就是比传统的嵌套结构快1.5倍)。

但是，当我使用一个函数来检查一个数字是否是素数时，filter()函数突然成为最快的。

我在下面发布了更多的细节，如果你想自己尝试的话，我会把代码上传到github上：test

我多次使用不同的范围最大值n测试代码，以确保结果是一致的，并且不受机器上某些临时后台进程的影响。

我的问题：

• 你知道为什么过滤函数在过滤偶数时速度这么慢吗？可能是因为lambda函数，还是因为我正在将生成器对象转换成列表？
• 为什么is_prime函数的结果如此相似，为什么过滤器函数在这里最快？

第一部分:收集偶数

( a)循环和其他-如果

even_nums = []
for i in range(1, n):
    if i % 2 == 0:
        even_nums.append(i)

( b)清单理解：

even = [i for i in range(1, n) if i % 2 == 0]

c) filter()函数

even_nums = list(filter((lambda x: x%2 != 0), range(1, n)))

is_even的结果

• 循环和其他-如果: 1x (参考)
• 列表理解:快1.5倍
• filter()函数:快0.9倍

第二部分:收集素数

def is_prime(num):
    """ Returns True if input integer is a prime number. """
    prime = True
    if num < 2:
        prime = False

    elif num == 2:
        prime = True
    else:
        for i in range(2, num):
            if num % i == 0:
                prime = False    
                break
    return prime

( a)循环和其他-如果

primes = []
for i in range(1, n):
    if is_prime(i):
        primes.append(i)

( b)清单理解：

primes = [i for i in range(1, n) if is_prime(i)]

c) filter()函数

primes = list(filter(is_prime, range(1, n)))

is_prime的结果

• 循环和其他-如果: 1x (参考)
• 列表理解速度:0.98倍
• filter()函数:1.13倍快

Answer 1

如果以这种方式实现第一个测试，则结果应该与第二个测试一致：

is_even = lambda i: i % 2 == 0
even = [i for i in range(1, n) if is_even(i)]

在filter实现中，每迭代一次函数调用( lambda)，这是一个额外的步骤。在第二个测试中不存在这种差异，因为在这种情况下，这两个实现已经包含了每次迭代一次的调用(is_prime)。

至于为什么filter稍微快一点，我怀疑这与filter是本地代码而不是python代码有关。考虑到列表理解仍然有一个额外的计算每次迭代的python代码:即，在i之前的for。在filter中，这个评估步骤是不必要的，因为它可以直接产生本机实现中的值。