gettimeofday/settimeofday関数の作成に時間がかからない

Question

かなり高価な操作を行う補助関数があります。

私はアルゴリズムのメインセクションをプロファイリングしようとしていますが、この補助関数は多く呼び出されます。したがって、測定された時間は補助機能の時間を考慮に入れます。

これを解決するために、補助的な機能が瞬間的に見えるように時間を設定して復元することに決めました。私は以下のマクロを定義しました：

#define TIME_SAVE struct timeval _time_tv; gettimeofday(&_time_tv,NULL); 
#define TIME_RESTORE settimeofday(&_time_tv,NULL); 

。 。それらを補助機能の最初と最後の行として使用しました。何らかの理由で、補助関数のオーバーヘッドが含まれています！

私はこれがちょっと面倒な解決策であることを知っています。それ以来私は動き続けましたが、なぜこのアイデアがうまくいかなかったのか不思議です。 誰かが理由を説明できますか？

Answer 1

発生している可能性がいくつかあります。 1つは、Linuxが時計を正確に保つことを試みており、クロックの調整がシステム内でスムーズな時間を保つために「スムーズ」または「修正」されている可能性があるということです。 NTPを実行している場合、それはまた、合理的な時間を維持しようとします。

私のアプローチは、クロックを変更するのではなく、プロセスの各部分が消費する時間を追跡することでした。高価な部分への呼び出しは蓄積されます（エントリ時と終了時のgettimeofdayの差をとり、累積することによって）、全体の時間からそれを減算します。より洗練されたアプローチのための他の可能性があります、私は確信しています。

Answer 2

このようにプロファイリングを主張する場合、はにシステムクロックを設定しません。あなたがそれを行う許可を持っている場合、これはあらゆる種類の事を破ります。基本的にはsettimeofdayのことを聞いたことを忘れるべきです。あなたがしたいことは、測定から除外したい機能の前後に両方ともgettimeofdayと呼んで差を計算することです。この機能で費やされた時間を全体の時間から除外することができます。

このように、「プロファイリング」の全体的な方法には大きな欠陥があります.gettimeofdayはおそらく（1）測定しようとしている時間に比べてかなりの時間がかかりますし、（2）おそらくカーネルスペースは、プログラムのキャッシュ一貫性に深刻なダメージを与えます。この2番目の問題は、実際にプログラムのパフォーマンス特性を観察しようとするときに、実際にプログラムを変更しようとする際に、最も問題になります。あなたが本当に何をすべき

は、プロファイリングのこの種（gettimeofdayあるいはGCCの-pg/GMONプロファイリング）を忘れて、代わりにoprofileまたはperfまたは類似のものを使用しています。これらの最新のプロファイリング技法は、命令ポインタおよび統計情報を統計的にサンプリングすることに基づいて動作する。プログラム自身のコードはまったく変更されていないため、プロファイラを実行していない場合の動作に可能な限り近い動作をします。