生成器表达式：性能异常？ [英] generator expressions: performance anomaly?
问题描述
请考虑以下时间，生成器表达式开始的时间比同等列表理解慢得多，并且变得更糟：
python -m timeit -sorig = range（100000） lst = orig [：]; lst [：] =（x代表x
in orig）"
10循环，最佳3：6.84e + 004 usec per loop
python -m timeit -s" orig = range（200000）" lst = orig [：]; lst [：] =（x代表x
in orig）"
10循环，最佳3：5.22e + 005 usec每循环
python -m timeit -s" orig = range（300000）" lst = orig [：]; lst [：] =（x代表x
in orig）"
10循环，最佳3：1.32e + 006 usec per loop
python -m timeit -s" orig = range（100000）" lst = orig [：]; lst [：] = [x代表x
in orig]"
10循环，最佳3：6.15e + 004 usec每循环
python -m timeit -s" orig = range（200000）" lst = orig [：]; lst [：] = [x代表x
in orig]"
10循环，最佳3：1.43e + 005 usec per loop
python -m timeit -s" orig = range（300000）" lst = orig [：]; lst [：] = [x for x
in orig]"
10循环，最好是3：每循环2.33e + 005 usec
规格：Python 2.4，Windows 2000,1.4GHz Athlon芯片，768Mb内存。
背景：最近有一个关于从列表中删除所有x实例的方法的线程。 / F建议列表理解为
构建结果列表。鉴于要求改变原始列表，
这需要赋值给lst [：]。我也试过了一台发电机
表达式。然而，虽然listcomp在百万元素列表中保持竞争力，但是genexp进入了外太空，大约是b
的20倍。上面的timeit运行显示了一个更简单的场景，
genexp似乎也是二次方。
评论，线索，...请。
TIA，
John
John Machin写道：
< blockquote class =post_quotes>鉴于要求改变原始列表，这需要分配
到lst [：]。
你总是拉凭空捏造的要求？
< / F>
John Machin写道：背景：有一个非常近期的线程，关于从列表中删除所有x实例的方法。 / F提出了列表理解来构建结果列表。鉴于要求改变原始列表，
这需要赋值给lst [：]。我也试过了一个生成器
表达式。然而，虽然listcomp保持竞争力达到百万元素列表，但是genexp进入了外太空，大约需要20倍的时间。上面的timeit运行显示了一个更简单的场景，其中genexp似乎也是二次方的。
评论，线索，......请。
Py> lc = [x代表范围内的x（100）]
Py> len（lc）
100
Py> ge =（x表示范围内的x（100））
Py> len（ge）
回溯（最近一次调用最后一次）：
文件"< stdin>"，第1行，在？
TypeError：未确定对象的len（）
如果传统已知长度输入的无条件ge传播，那将是很好的，但这不是目前的情况。有一个类似的性能
与从生成器表达式构造元组相关联的故障（使用
vanilla 2.4，绕过列表实际上更快）
干杯，
尼克。
-
Nick Coghlan | nc******@email.com |澳大利亚布里斯班
--------------------------------------- ------------------------
http://boredomandlaziness.skystorm.net
Fredrik Lundh写道：John Machin写道：
鉴于要求改变原始列表，这需要
赋值给lst [：]。
<你总是凭空掏空要求吗？
< / F>
我有兴趣做一个公平的比较从列表中删除多个事件的所有提议的
方法之间，以及
多数人在列表中置换列表，我在listcomp
和genexp方法进入同一个模具。如果你选择用空气来描述那个
，请随意。
你对生成器表达式为什么会有任何建议
的表现比同等的列表理解差得多吗？
[OT]
无论如何，我没有时间讨厌 - 现在聊天。我的妻子为圣诞节买了一台价值相机的b
并将一大堆500万像素的JPEG转发给我，我正在编写一个快速脚本来调整大小他们，
使用我刚从网上下载的一些成像库，由
来自瑞典的一些脾气暴躁的PILlock，显然:-)
干杯，
John
Please consider the timings below, where a generator expression starts
out slower than the equivalent list comprehension, and gets worse:
python -m timeit -s "orig=range(100000)" "lst=orig[:];lst[:]=(x for x in orig)"
10 loops, best of 3: 6.84e+004 usec per loop
python -m timeit -s "orig=range(200000)" "lst=orig[:];lst[:]=(x for x in orig)"
10 loops, best of 3: 5.22e+005 usec per loop
python -m timeit -s "orig=range(300000)" "lst=orig[:];lst[:]=(x for x in orig)"
10 loops, best of 3: 1.32e+006 usec per loop
python -m timeit -s "orig=range(100000)" "lst=orig[:];lst[:]=[x for x in orig]"
10 loops, best of 3: 6.15e+004 usec per loop
python -m timeit -s "orig=range(200000)" "lst=orig[:];lst[:]=[x for x in orig]"
10 loops, best of 3: 1.43e+005 usec per loop
python -m timeit -s "orig=range(300000)" "lst=orig[:];lst[:]=[x for x
in orig]"
10 loops, best of 3: 2.33e+005 usec per loop
Specs: Python 2.4, Windows 2000, 1.4GHz Athlon chip, 768Mb of memory.
Background: There was/is a very recent thread about ways of removing
all instances of x from a list. /F proposed a list comprehension to
build the result list. Given a requirement to mutate the original list,
this necessitates the assignment to lst[:]. I tried a generator
expression as well. However while the listcomp stayed competitive up to
a million-element list, the genexp went into outer space, taking about
20 times as long. The above timeit runs show a simpler scenario where
the genexp also seems to be going quadratic.
Comments, clues, ... please.
TIA,
John
John Machin wrote:
Given a requirement to mutate the original list, this necessitates the assignment
to lst[:].
do you always pull requirements out of thin air?
</F>
John Machin wrote:Background: There was/is a very recent thread about ways of removing
all instances of x from a list. /F proposed a list comprehension to
build the result list. Given a requirement to mutate the original list,
this necessitates the assignment to lst[:]. I tried a generator
expression as well. However while the listcomp stayed competitive up to
a million-element list, the genexp went into outer space, taking about
20 times as long. The above timeit runs show a simpler scenario where
the genexp also seems to be going quadratic.
Comments, clues, ... please.
Py> lc = [x for x in range(100)]
Py> len(lc)
100
Py> ge = (x for x in range(100))
Py> len(ge)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: len() of unsized object
It would be nice if unconditional ge''s with known length inputs propagated
__len__, but that is not currently the case. There''s a similar performance
glitch associated with constructing a tuple from a generator expression (with
vanilla 2.4, detouring via list is actually faster)
Cheers,
Nick.
--
Nick Coghlan | nc******@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
Fredrik Lundh wrote:John Machin wrote:Given a requirement to mutate the original list, this necessitates the assignment to lst[:].
do you always pull requirements out of thin air?
</F>
I was interested in doing a fair comparison between all the proposed
methods of deleting multiple occurrences from a list, and as the
majority were permuting the list in place, I shoe-horned the listcomp
and genexp methods into the same mould. If you choose to describe that
as pulling requirements out of thin air, feel free.
Do you have any suggestions as to why a generator expression would
perform much worse than the equivalent list comprehension?
[OT]
Anyway, I don''t have time for chit-chat right now. My wife got a
digital camera for Xmas and dumped a whole bunch of 5 megapixel JPEGs
on me and I''m in the middle of writing a quick script to resize them,
using some imaging library I just downloaded off the web, written by
some grumpy PILlock from Sweden, evidently :-)
Cheers,
John
这篇关于生成器表达式：性能异常？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
