进行一些性能评估，
timeit而不是尝试使用手动进行
time。
首先，Apple 2.7.2 64位：
In [37]: %timeit collections.deque((x for x in xrange(10000000) if x%4 == 0), maxlen=0)1 loops, best of 3: 1.05 s per loop
现在，python.org 3.3.0 64位：
In [83]: %timeit collections.deque((x for x in range(10000000) if x%4 == 0), maxlen=0)1 loops, best of 3: 1.32 s per loopIn [84]: %timeit collections.deque((x for x in xrange(10000000) if x%4 == 0), maxlen=0)1 loops, best of 3: 1.31 s per loopIn [85]: %timeit collections.deque((x for x in iter(range(10000000)) if x%4 == 0), maxlen=0) 1 loops, best of 3: 1.33 s per loop
显然，3.x
range确实比2.x慢一些
xrange。OP的
xrange功能与此无关。（不足为奇，因为
__iter__在循环中发生的任何事情的1000万次调用中，对插槽的一次性调用不太可能看到，但有人提出来了。）
但这仅慢了30％。OP如何使速度慢2倍？好吧，如果我对32位Python重复相同的测试，则得出的结果是1.58和3.12。因此，我的猜测是，这是3.x针对64位性能进行了优化（以损害32位的方式）的又一案例。
但这真的重要吗？再次使用64位3.3.0进行检查：
In [86]: %timeit [x for x in range(10000000) if x%4 == 0]1 loops, best of 3: 3.65 s per loop
因此，构建所需的
list时间是整个迭代的两倍以上。
至于“比Python
2.6+消耗更多的资源”，在我的测试中，看起来3.x
range的大小与2.x的大小完全相同
xrange，即使它的大小是10x的大小，也可以构建不必要的列表问题仍然比范围迭代可能做的任何事情多出10000000x。
那么显式
for循环而不是内部的C循环
deque呢？
In [87]: def consume(x): ....: for i in x: ....: passIn [88]: %timeit consume(x for x in range(10000000) if x%4 == 0)1 loops, best of 3: 1.85 s per loop
因此，在
for语句中浪费的时间几乎与迭代的实际工作一样多
range。
如果您担心优化范围对象的迭代，则可能在错误的位置。
同时，
xrange无论人们告诉您相同的内容多少次，您都会不断询问为什么要删除它，但是我会再次重复：它没有被删除：它被重命名为
range，而2.x
range是被删除的。
这是3.3
range对象是2.x
xrange对象（而不是2.x
range函数）的直接后代的证明：3.3
range和2.7
xrange的源。您甚至可以查看更改历史记录（我相信，该更改已链接到替换文件中任何位置的字符串“
xrange”的最后一个实例的更改）。
那么，为什么它变慢？
好吧，其中之一是，他们添加了许多新功能。另一方面，他们已经在整个地方（尤其是在迭代过程中）进行了各种具有较小副作用的更改。尽管有时有时会稍微低估不太重要的案例，但仍进行了大量工作来显着优化各种重要案例。将所有这些加起来，
range对于尽快进行迭代现在变得慢一点，我并不感到惊讶。这是最重要的案例之一，没有人会足够关注。没有人会遇到现实生活中的用例，这种性能差异是他们代码中的热点。
