python - time.time() は time.clock() より速いですか?

Question

外部ライブラリを使用して、大量のデータを反復処理し、それぞれで関数を実行する Python でテストを作成しています。各ループでは、何らかの方法でデータをデコードしてマングルする必要がある場合もあります。現在、ベンチマークは最優先事項ではありませんが、実際のテストとの違いやマングリングによるオーバーヘッド (手に負えなくなった場合) などの基本的な統計を測定したいと考えています。

SO answerを含むほとんどの情報源は timeit モジュールの使用を提案しているようですが、それらのほとんどは単純なコード スニペットのベンチマークについて話しているようです。また、答えが指摘しているように、 time.clock() はそのために推奨されているようです。

しかし、2 つの通話の実際の速度を比較したものは見つかりませんでした。だから私は time.time と time.clock を使ってどちらが速いかを実験してきましたが、驚くべきことに time.time() が勝者のようです。

このコード (「最適化の逸話」から借用):

import time

def timing0(f, n):
    print f.__name__,
    r = range(n)
    t1 = time.clock()
    for i in r:
        f(); f(); f(); f(); f()
        f(); f(); f(); f(); f()
    t2 = time.clock()
    print t2-t1

timing0(time.clock, 1000000)
timing0(time.time, 1000000)

ほとんど常に次のような数値を出力します。

me@here:~$ ./timing_time
clock 2.47
time 0.47
me@here:~$

唯一の違いは、time() の方がはるかに正確であるということです。測定に time() を使用すると、小数点以下約 11 桁になります。

しかし、time() は、精度が低くても、常に約 5 倍高速です。

では、なぜ clock() が好まれるのでしょうか? これはアーキテクチャと OS に大きく依存しますか? または、何かが欠けていて、結果が正しくありませんか?

上記のコードは、Debian Wheezy amd64 および Python 2.7 で実行されました。OpenVZ で実行されている Python 2.6 を使用して Squeeze amd64 で試してみましたが、結果はほぼ同じでした。