【发布时间】:2017-02-05 12:29:06
【问题描述】:
我在 16GB、2.7GHz i5、OSX 10.11.5 机器上运行 Python 2.7.10。
我在许多不同类型的示例中多次观察到这种现象,因此下面的示例虽然有点做作,但具有代表性。这正是我今天早些时候碰巧在做的事情,当时我的好奇心终于被激起了。
>>> timeit('unicodedata.category(chr)', setup = 'import unicodedata, random; chr=unichr(random.randint(0,50000))', number=100)
3.790855407714844e-05
>>> timeit('unicodedata.category(chr)', setup = 'import unicodedata, random; chr=unichr(random.randint(0,50000))', number=1000)
0.0003371238708496094
>>> timeit('unicodedata.category(chr)', setup = 'import unicodedata, random; chr=unichr(random.randint(0,50000))', number=10000)
0.014712810516357422
>>> timeit('unicodedata.category(chr)', setup = 'import unicodedata, random; chr=unichr(random.randint(0,50000))', number=100000)
0.029777050018310547
>>> timeit('unicodedata.category(chr)', setup = 'import unicodedata, random; chr=unichr(random.randint(0,50000))', number=1000000)
0.21139287948608398
您会注意到,从 100 到 1000,时间增加了 10 倍,正如预期的那样。但是,从 1e3 到 1e4,它更像是 50 的因数,然后是从 1e4 到 1e5 的 2 倍(所以从 1e3 到 1e5 的总因数是 100,这是预期的)。
我认为无论是在计时的实际过程中还是在 timeit 本身中,都必须进行某种基于缓存的优化,但我无法凭经验判断是否是这种情况。导入似乎并不重要,可以通过一个最基本的示例观察到这一点:
>>> timeit('1==1', number=10000)
0.0005490779876708984
>>> timeit('1==1', number=100000)
0.01579904556274414
>>> timeit('1==1', number=1000000)
0.04653501510620117
从 1e4 到 1e6 存在 1e2 时间差的真实因子,但中间步骤是 ~30 和 ~3。
我可以进行更多的临时数据收集,但目前我还没有想到任何假设。
关于为什么在某些中间运行次数处出现非线性比例的任何概念?
【问题讨论】:
-
我没有具体的答案给你,但在这些小时间尺度上,很难确切知道环境(你的计算机)中可能发生的其他什么事情会导致时间波动。 .
-
只需运行
timeit('1==1', number=10000)多次并观察波动。你基本上是在观察噪音。您的进程可能被其他进程抢占,或者计时器的分辨率可能不够高,无法准确解决如此短的时间。
标签: python performance optimization timeit