列出索引效率（python 2 vs python 3） [英] List indexing efficiency (python 2 vs python 3)

问题描述

在回答另一个问题时，我建议使用 timeit 测试使用正整数和负整数索引列表之间的区别。这是代码：

  import timeit 
t = timeit.timeit（'mylist [99]'，setup ='mylist = list（range（100））'，number = 10000000）
 print（t）
t = timeit.timeit（'mylist [-1]'，setup ='mylist = list（range（100） ）'，number = 10000000）
 print（t）
  

我用python运行此代码2.6：

  $ python2.6 test.py 
 0.587687015533 
 0.586369991302 
  

然后我用python 3.2运行它：

  $ python3.2 test.py 
 0.9212150573730469 
 1.0225799083709717 
  

然后我挠了挠头，做了一些谷歌搜索，决定在这里发布这些观察结果。

操作系统：OS-X（10.5.8） - Intel Core2Duo

这对我来说似乎是一个非常显着的差异（差异超过1.5）。有没有人知道为什么python3这么慢 - 特别是对于这种常见的操作？

编辑

我在我的Ubuntu Linux桌面（Intel i7）上运行相同的代码，并使用python2.6和python 3.2获得了可比较的结果。这似乎是一个依赖于操作系统（或处理器）的问题（其他用户在Linux机器上看到相同的行为 - 请参阅注释）。

编辑2

在其中一个答案中请求启动横幅，所以这里是：

  Python 2.6.4（r264：75821M，2009年10月27日，19：48：32）
 [GCC 4.0.1（Apple Inc. build 5493）]在darwin 
  

和：

  Python 3.2（r32：88452，2011年2月20日，10：19：59）
 [GCC 4.0.1（Apple Inc. build 5493）]在darwin 
  

更新

我刚刚安装了新版本的来自 http://www.python.org/download/ 的python2.7.3和python3.2.3 / p>

在这两种情况下，我都拿了

Python xx3 Mac OS X 32位i386 / PPC安装程序（适用于Mac OS X 10.3到10.6 [2]）

因为我在OS X 10.5上。以下是新时间（通过多次试验合理一致）：

python 2.7

  $ python2.7 test.py 
 0.577006101608 
 0.590042829514 
  

python 3.2.3

  $ python3.2 test.py 
 0.8882801532745361 
 1.034242868423462 
  

解决方案

这似乎是Python 3.2某些版本的工件。在这一点上，最好的假设是所有32位英特尔版本都有减速，但没有64位版本。继续阅读以获取更多详细信息。

您没有运行足够的测试来确定任何内容。多次重复测试，我在同一测试中得到的值介于0.31到0.54之间，这是一个巨大的变化。

所以，我用<运行你的测试code> 10x 数字， repeat = 10 ，使用一堆不同的Python2和Python3安装。丢掉顶部和底部的结果，平均其他8，然后除以10（得到一个相当于你的测试的数字），这就是我所看到的：

  1. 0.52 / 0.53 Lion 2.6 
 2. 0.49 / 0.50 Lion 2.7 
 3. 0.48 / 0.48 MacPorts 2.7 
 4. 0.39 / 0.49 MacPorts 3.2 
 5. 0.39 / 0.48 HomeBrew 3.2 
  

因此，看起来3.2实际上稍快一点 [99] ，与 [ - 1] 的速度差不多。

然而，在10.5机器上，我得到了这些结果：

  1. 0.98 / 1.02 MacPorts 2.6 
 2. 1.47 / 1.59 MacPorts 3.2 
  

回到原来的（Lion）机器，我跑了32比特模式，得到这个：

  1. 0.50 / 0.48 Homebrew 2.7 
 2. 0.75 / 0.82 Homebrew 3.2 
  

所以，似乎32位是重要的，而不是Leopard vs. Lion，gcc 4.0与gcc 4.2或clang，硬件差异等等。他会lp用于测试Leopard下的64位版本，使用不同的编译器等，但不幸的是我的Leopard盒子是第一代Intel Mini（带有32位Core Solo CPU），所以我不能做那个测试。 / p>

作为进一步的间接证据，我在Lion盒子上运行了一系列其他快速测试，看起来32位3.2比2.x慢〜50％虽然64位3.2可能比2.x快一点。但是如果我们真的想要支持那个，那么有人需要选择并运行一个真正的基准测试套件。

无论如何，我最好的猜测是在优化3时.x分支，没人在32位i386 Mac版本上投入太多精力。这对他们来说实际上是一个合理的选择。

或者，他们甚至没有在32位i386期间投入太多精力。这种可能性可以解释为什么OP看到2.x和3.2在linux盒子上给出类似的结果，而Otto Allmendinger看到3.2在linux盒子上同样慢到2.6。但由于他们都没有提到他们是在运行32位还是64位Linux，因此很难知道这是否相关。

还有很多其他不同的可能性我们没有排除，但这似乎是最好的。

In answering another question, I suggested to use timeit to test the difference between indexing a list with positive integers vs. negative integers. Here's the code:

import timeit
t=timeit.timeit('mylist[99]',setup='mylist=list(range(100))',number=10000000)
print (t)
t=timeit.timeit('mylist[-1]',setup='mylist=list(range(100))',number=10000000)
print (t)

I ran this code with python 2.6:

$ python2.6 test.py
0.587687015533
0.586369991302

Then I ran it with python 3.2:

$ python3.2 test.py
0.9212150573730469
1.0225799083709717

Then I scratched my head, did a little google searching and decided to post these observations here.

Operating system: OS-X (10.5.8) -- Intel Core2Duo

That seems like a pretty significant difference to me (a factor of over 1.5 difference). Does anyone have an idea why python3 is so much slower -- especially for such a common operation?

EDIT

I've run the same code on my Ubuntu Linux desktop (Intel i7) and achieved comparable results with python2.6 and python 3.2. It seems that this is an issue which is operating system (or processor) dependent (Other users are seeing the same behavior on Linux machines -- See comments).

EDIT 2

The startup banner was requested in one of the answers, so here goes:

Python 2.6.4 (r264:75821M, Oct 27 2009, 19:48:32) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin

and:

Python 3.2 (r32:88452, Feb 20 2011, 10:19:59) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin

UPDATE

I've just installed fresh versions of python2.7.3 and python3.2.3 from http://www.python.org/download/

In both cases, I took the

"Python x.x.3 Mac OS X 32-bit i386/PPC Installer (for Mac OS X 10.3 through 10.6 [2])"

since I am on OS X 10.5. Here are the new timings (which are reasonably consistent through multiple trials):

python 2.7

$python2.7 test.py
0.577006101608
0.590042829514

python 3.2.3

$python3.2 test.py
0.8882801532745361
1.034242868423462

解决方案

This appears to be an artifact of some builds of Python 3.2. The best hypothesis at this point is that all 32-bit Intel builds have the slowdown, but no 64-bit ones do. Read on for further details.

You didn't run nearly enough tests to determine anything. Repeating your test a bunch of times, I got values ranging from 0.31 to 0.54 for the same test, which is a huge variation.

So, I ran your test with 10x the number, and repeat=10, using a bunch of different Python2 and Python3 installs. Throwing away the top and bottom results, averaging the other 8, and dividing by 10 (to get a number equivalent to your tests), here's what I saw:

 1. 0.52/0.53 Lion 2.6
 2. 0.49/0.50 Lion 2.7
 3. 0.48/0.48 MacPorts 2.7
 4. 0.39/0.49 MacPorts 3.2
 5. 0.39/0.48 HomeBrew 3.2

So, it looks like 3.2 is actually slightly faster with [99], and about the same speed with [-1].

However, on a 10.5 machine, I got these results:

 1. 0.98/1.02 MacPorts 2.6
 2. 1.47/1.59 MacPorts 3.2

Back on the original (Lion) machine, I ran in 32-bit mode, and got this:

 1. 0.50/0.48 Homebrew 2.7
 2. 0.75/0.82 Homebrew 3.2

So, it seems like 32-bitness is what matters, and not Leopard vs. Lion, gcc 4.0 vs. gcc 4.2 or clang, hardware differences, etc. It would help to test 64-bit builds under Leopard, with different compilers, etc., but unfortunately my Leopard box is a first-gen Intel Mini (with a 32-bit Core Solo CPU), so I can't do that test.

As further circumstantial evidence, I ran a whole slew of other quick tests on the Lion box, and it looks like 32-bit 3.2 is ~50% slower than 2.x, while 64-bit 3.2 is maybe a little faster than 2.x. But if we really want to back that up, someone needs to pick and run a real benchmark suite.

Anyway, my best guess at this point is that when optimizing the 3.x branch, nobody put much effort into 32-bit i386 Mac builds. Which is actually a reasonable choice for them to have made.

Or, alternatively, they didn't even put much effort into 32-bit i386 period. That possibility might explain why the OP saw 2.x and 3.2 giving similar results on a linux box, while Otto Allmendinger saw 3.2 being similarly slower to 2.6 on a linux box. But since neither of them mentioned whether they were running 32-bit or 64-bit linux, it's hard to know whether that's relevant.

There are still lots of other different possibilities that we haven't ruled out, but this seems like the best one.

这篇关于列出索引效率（python 2 vs python 3）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！