我正在回答这个 question ，我更喜欢这里的生成器表达式并使用了这个，我认为这会更快，因为生成器不需要先创建整个列表:

>>> lis=[['a','b','c'],['d','e','f']]
>>> 'd' in (y for x in lis for y in x)
True

Levon 在他的 solution 中使用了列表理解。 ,

>>> lis = [['a','b','c'],['d','e','f']]
>>> 'd' in [j for i in mylist for j in i]
True

但是当我做这些 LC 的 timeit 结果比生成器快时:

~$ python -m timeit -s "lis=[['a','b','c'],['d','e','f']]" "'d' in (y for x in lis for y in x)"
    100000 loops, best of 3: 2.36 usec per loop
~$ python -m timeit -s "lis=[['a','b','c'],['d','e','f']]" "'d' in [y for x in lis for y in x]"
    100000 loops, best of 3: 1.51 usec per loop

然后我增加了列表的大小，并再次计时:

lis=[['a','b','c'],['d','e','f'],[1,2,3],[4,5,6],[7,8,9],[10,11,12],[13,14,15],[16,17,18]]

这次搜索 'd' 生成器比 LC 快，但是当我搜索中间元素(11)和最后一个元素时，LC 再次击败生成器表达式，我不能明白为什么吗？

~$ python -m timeit -s "lis=[['a','b','c'],['d','e','f'],[1,2,3],[4,5,6],[7,8,9],[10,11,12],[13,14,15],[16,17,18]]" "'d' in (y for x in lis for y in x)"
    100000 loops, best of 3: 2.96 usec per loop

~$ python -m timeit -s "lis=[['a','b','c'],['d','e','f'],[1,2,3],[4,5,6],[7,8,9],[10,11,12],[13,14,15],[16,17,18]]" "'d' in [y for x in lis for y in x]"
    100000 loops, best of 3: 7.4 usec per loop

~$ python -m timeit -s "lis=[['a','b','c'],['d','e','f'],[1,2,3],[4,5,6],[7,8,9],[10,11,12],[13,14,15],[16,17,18]]" "11 in [y for x in lis for y in x]"
100000 loops, best of 3: 5.61 usec per loop

~$ python -m timeit -s "lis=[['a','b','c'],['d','e','f'],[1,2,3],[4,5,6],[7,8,9],[10,11,12],[13,14,15],[16,17,18]]" "11 in (y for x in lis for y in x)"
100000 loops, best of 3: 9.76 usec per loop

~$ python -m timeit -s "lis=[['a','b','c'],['d','e','f'],[1,2,3],[4,5,6],[7,8,9],[10,11,12],[13,14,15],[16,17,18]]" "18 in (y for x in lis for y in x)"
100000 loops, best of 3: 8.94 usec per loop

~$ python -m timeit -s "lis=[['a','b','c'],['d','e','f'],[1,2,3],[4,5,6],[7,8,9],[10,11,12],[13,14,15],[16,17,18]]" "18 in [y for x in lis for y in x]"
100000 loops, best of 3: 7.13 usec per loop

最佳答案

在 Paulo 上展开的答案，由于函数调用的开销，生成器表达式通常比列表推导式慢。在这种情况下，in 的短路行为如果相当早地找到该项目，则可以抵消这种缓慢，否则，该模式成立。

我通过分析器运行了一个简单的脚本以进行更详细的分析。这是脚本:

lis=[['a','b','c'],['d','e','f'],[1,2,3],[4,5,6],
     [7,8,9],[10,11,12],[13,14,15],[16,17,18]]

def ge_d():
    return 'd' in (y for x in lis for y in x)
def lc_d():
    return 'd' in [y for x in lis for y in x]

def ge_11():
    return 11 in (y for x in lis for y in x)
def lc_11():
    return 11 in [y for x in lis for y in x]

def ge_18():
    return 18 in (y for x in lis for y in x)
def lc_18():
    return 18 in [y for x in lis for y in x]

for i in xrange(100000):
    ge_d()
    lc_d()
    ge_11()
    lc_11()
    ge_18()
    lc_18()

以下是相关结果，已重新排序以使模式更清晰。

         5400002 function calls in 2.830 seconds

   Ordered by: standard name

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
   100000    0.158    0.000    0.251    0.000 fop.py:3(ge_d)
   500000    0.092    0.000    0.092    0.000 fop.py:4(<genexpr>)
   100000    0.285    0.000    0.285    0.000 fop.py:5(lc_d)

   100000    0.356    0.000    0.634    0.000 fop.py:8(ge_11)
  1800000    0.278    0.000    0.278    0.000 fop.py:9(<genexpr>)
   100000    0.333    0.000    0.333    0.000 fop.py:10(lc_11)

   100000    0.435    0.000    0.806    0.000 fop.py:13(ge_18)
  2500000    0.371    0.000    0.371    0.000 fop.py:14(<genexpr>)
   100000    0.344    0.000    0.344    0.000 fop.py:15(lc_18)

创建一个生成器表达式相当于creating a generator function and calling it .这占了一次调用 <genexpr> .然后，在第一种情况下，next被调用 4 次，直到 d达到，总共 5 次调用(乘以 100000 次迭代 = ncalls = 500000)。第二种情况，调用了17次，总共调用了18次；第三次，24 次，总共 25 次调用。

genex 在第一种情况下优于列表理解，但对 next 的额外调用在第二种和第三种情况下，列表理解的速度和生成器表达式的速度之间的差异占了大部分。

>>> .634 - .278 - .333
0.023
>>> .806 - .371 - .344
0.091

我不确定剩余时间的原因；即使没有额外的函数调用，生成器表达式似乎也会慢一些。我想这证实了inspectorG4dget的断言“创建生成器推导比列表推导具有更多的本地开销。”但无论如何，这很清楚地表明生成器表达式较慢主要是因为调用了 next .

我要补充一点，当短路没有帮助时，列表推导式仍然更快，即使对于非常大的列表也是如此。例如:

>>> counter = itertools.count()
>>> lol = [[counter.next(), counter.next(), counter.next()] 
           for _ in range(1000000)]
>>> 2999999 in (i for sublist in lol for i in sublist)
True
>>> 3000000 in (i for sublist in lol for i in sublist)
False
>>> %timeit 2999999 in [i for sublist in lol for i in sublist]
1 loops, best of 3: 312 ms per loop
>>> %timeit 2999999 in (i for sublist in lol for i in sublist)
1 loops, best of 3: 351 ms per loop
>>> %timeit any([2999999 in sublist for sublist in lol])
10 loops, best of 3: 161 ms per loop
>>> %timeit any(2999999 in sublist for sublist in lol)
10 loops, best of 3: 163 ms per loop
>>> %timeit for i in [2999999 in sublist for sublist in lol]: pass
1 loops, best of 3: 171 ms per loop
>>> %timeit for i in (2999999 in sublist for sublist in lol): pass
1 loops, best of 3: 183 ms per loop

如您所见，当短路无关紧要时，列表推导始终更快，即使对于一百万个列表的列表也是如此。显然对于 in 的实际使用在这些规模上，由于短路，发电机会更快。但对于其他类型的项目数量真正线性的迭代任务，列表推导式总是快得多。如果您需要对一个列表执行多个测试，则尤其如此；你可以迭代一个已经构建的列表理解非常快:

>>> incache = [2999999 in sublist for sublist in lol]
>>> get_list = lambda: incache
>>> get_gen = lambda: (2999999 in sublist for sublist in lol)
>>> %timeit for i in get_list(): pass
100 loops, best of 3: 18.6 ms per loop
>>> %timeit for i in get_gen(): pass
1 loops, best of 3: 187 ms per loop

在这种情况下，列表理解要快一个数量级!

当然，只有在内存耗尽之前，这才是正确的。这让我想到了最后一点。使用发电机有两个主要原因:利用短路和节省内存。对于非常大的序列/可迭代对象，生成器是显而易见的方法，因为它们可以节省内存。但如果短路不是一种选择，您几乎永远选择生成器而不是速度列表。您选择它们​​是为了节省内存，这始终是一种权衡。

关于python - 列表理解与生成器表达式的奇怪 timeit 结果？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11964130/