Question

所以我想比较2.6和3.1之间python的性能，所以我编写了这个简单的程序test.py，它将执行一些基本的冗长操作：

from time import time
start = time()
q = 2 ** 1000000000
q += 3 << 1000000000
print(q.__sizeof__(), time() - start)

我没有得到我的预期，因为在分别启动命令time python2.6 test.py和time python3.1 test.py之后，输出如下：

(133333364, 0.37349200248718262)

real    0m35.586s
user    0m28.130s
sys 0m2.110s

和

133333360 0.312520027161

real    0m26.413s
user    0m17.330s
sys 0m2.190s

我认为在比较time命令的输出和程序内部的输出时，两个版本的结果都会接近。对此有何解释？

Answer 1

可能有很多解释，例如sys.path上的一组不同的目录（和zip文件），初始化时自动加载/执行的代码，平台上运行的其他进程 - 您的代码根本没有被隔离也不可重复，因此其结果价值很小。使用python -mtimeit来衡量一些事情，更多更好。

修改：有些数字......：

$ py26 -mtimeit 'q=2**1000000000; q+=3<<1000000000'
10 loops, best of 3: 466 msec per loop
$ py31 -mtimeit 'q=2**1000000000; q+=3<<1000000000'
10 loops, best of 3: 444 msec per loop

这些准确地测量+=时间（在3.1中略微更好/更优化，可重复）。如果你想衡量转移或提升权力次，那么你当然不能使用文字（因为文字表达式是在编译时计算的，而不是在运行时计算的）时间：为什么您希望所有重要代码都在模块中的函数，不在顶级代码中或在主脚本中...的原因的一部分...因此编译器可以执行尽可能多的工作虽然没有任何严肃的优化，但是很容易实现;-)。 E.g：

$ py31 -mtimeit -s't=2' 'q=t**1000000'
10 loops, best of 3: 19.4 msec per loop
$ py31 -mtimeit -s't=3' 'q=t<<1000000'
10000 loops, best of 3: 150 usec per loop

（用你使用的更大的RHS操作数来做它们需要太长时间，而且我会变得不耐烦;-)。混合操作在测量方面当然是一个悲伤的灾难，因为相对较快的操作基本上会在混合中消失！ - 幸运的是，这种混合没有充分的理由 - 毕竟，timeit用于微基准测试！ - ）

Answer 2

嘿，迭代问题，花了我一段时间来搞清楚：

from time import time
start = time()
q = 2 ** 1000000000 # number literal
q += 3 << 1000000000 # still a literal
print(q.__sizeof__(), time() - start)

Python的编译器（！）计算q。当脚本运行时，解释器会花时间，加载已经计算的值并再次花费时间。现在不出所料，这两次几乎是一样的。

另一方面，

time测量完整运行（编译+运行）所需的时间。

计算python中的已用时间时出现混乱？

2 个答案: