![](/img/trans.png)
[英]Why does IPython `%timeit` yield a slower time for an O(n) solution?
[英]Why does timeit report slower code as faster one?
我在 Debian Stretch 中使用 python 3.5 对此进行了测试。
我尝试对“避免点”优化进行基准测试。
正如预期的那样, “避免点”优化确实要快得多。
出乎意料的是,timeit 报告速度越慢的代码越快。 是什么原因?
$ time python3 -m timeit -s "s=''" "s.isalpha()"
10000000 loops, best of 3: 0.119 usec per loop
real 0m5.023s
user 0m4.922s
sys 0m0.012s
$ time python3 -m timeit -s "isalpha=str.isalpha;s=''" "isalpha(s)"
1000000 loops, best of 3: 0.212 usec per loop
real 0m0.937s
user 0m0.927s
sys 0m0.000s
timeit
在“慢”的情况下进行了 10 倍的迭代。 它自适应地尝试更多的迭代来找到一个平衡统计质量和等待时间的数字。
感谢戴维斯鲱鱼的回答。
让我们了解更多细节:
从python3 -m timeit -h
:
If -n is not given, a suitable number of loops is calculated by trying
successive powers of 10 until the total time is at least 0.2 seconds.
通过计算详细信息验证:
$ time python3 -m timeit -v -s "s=''" "s.isalpha()"
10 loops -> 3.44e-06 secs
100 loops -> 1.29e-05 secs
1000 loops -> 0.000117 secs
10000 loops -> 0.00116 secs
100000 loops -> 0.0118 secs
1000000 loops -> 0.116 secs
10000000 loops -> 1.17 secs
raw times: 1.21 1.21 1.21
10000000 loops, best of 3: 0.121 usec per loop
real 0m4.992s
user 0m4.977s
sys 0m0.012s
所有x loops -> y secs
时间总和用于确定合适的循环数。
“原始时间”行中的每个项目都是单个重复计时器结果( -r
选项确定“原始时间”行中的项目数)。
几乎所有时间都匹配:
>>> 3.44e-06+1.29e-05+0.000117+0.00116+0.0118+0.116+1.17+1.21+1.21+1.21
4.92909334
>>> 4.992-4.92909334
0.06290666000000034
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.