プログラムでいくつかの評価測定を実行して、実行時間をテストし、元のシステムの実行をチェックするトレーサーが元のシステムのパフォーマンスにどのように影響するかをテストしています。トレースプログラムはシステムに干渉せず、トレースメッセージの受信を除いてシステム間の通信は行われません。
953.14これまでの結果は、トレースがオンになっているマイクロ秒と比較して、トレースがオンになっていないプログラムの平均マイクロ秒です937。タイミングは関数を使用して計算されstatistics(wall_clock)ます。
私の考えは、トレーサーからの追加のプロセスがあり、トレースメカニズムには独自の処理能力が必要になるため、システムを高速化するのではなく低速化するというものでした。これが発生する可能性がある既知の理由はありますか？
メジャーを1回または数回実行しましたか？wall_clockを使用すると、環境の潜在的な摂動をこの測定に含め、メッセージを待ちます...、CPU時間を評価しません。以下の例はそれを示しています：
1> F = fun() -> receive _ -> ok after 5000 -> timout end end.
#Fun<erl_eval.20.111823515>
2> F().
timout
3> statistics(wall_clock),F(),statistics(wall_clock).
{965829,5016}
4>
関数Fは明らかに5秒のCPU時間を必要としませんが、5秒だけ待機します。
これは、測定を数回行う必要があることを意味します。通常、モジュールコードをロードするために必要な時間を含む可能性のある最初の実行時間を使用せず、環境に注意します。同じマシンで実行されている他のプロセスは何ですか。測定された時間が待機状態の結果ではないことを確認してください。
wall_clockの代わりにruntimeを使用すると、必要なCPU時間が表示されるため、コードをトレースするときに時間が長くなります。この時間の増加は、マルチコアの使用によって隠される可能性があることに注意してください。