私はPython 2.7.10を、16GB、2.7GHzのi5、OSX 10.11.5マシンで実行しています。pythonの `timeit`は常に数値で直線的に拡大するとは限りませんか?
多くの異なるタイプの例でこの現象が何度も観察されています。したがって、下の例は、少し工夫してありますが、代表的な例です。それは、私の好奇心が最終的にはっきりした今日の私が働いていたことです。
>>> 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。
アドホックなデータ収集をもっと行うことができますが、この時点では仮説はありません。
なぜ特定の中間回数で非線形のスケールが発生するのか?
私はあなたのための具体的な答えを持っていないが、これらの小さなタイムスケールでそれは難しいですあなたのコンピュータ(あなたのコンピュータ)でタイミングの変動を引き起こす可能性があることを正確に知るために... – mgilson
'timeit( '1 == 1'、number = 10000)'を複数回実行し、その変動を観察します。あなたは基本的にノイズを観測しています。プロセスが他のプロセスによってプリエンプトされている可能性があります。そうしないと、タイマーの解像度が正確に短くなっていない可能性があります。 –