かなりコストのかかるいくつかの操作を行う補助関数があります。
アルゴリズムのメイン セクションをプロファイリングしようとしていますが、この補助関数は内部で頻繁に呼び出されます。したがって、測定時間には補助機能の時間が考慮されます。
これを解決するために、補助機能が瞬時に見えるように時間を設定して復元することにしました。次のマクロを定義しました。
#define TIME_SAVE struct timeval _time_tv; gettimeofday(&_time_tv,NULL);
#define TIME_RESTORE settimeofday(&_time_tv,NULL);
. . . それらを補助関数の最初と最後の行として使用しました。ただし、何らかの理由で、補助関数のオーバーヘッドがまだ含まれています。
だから、私はこれが厄介な解決策であることを知っています. 誰かが理由を説明してもらえますか?
この方法でプロファイリングを行う場合は、システムクロックを設定しないでください。あなたがそれをする許可を持っているならば、これはあらゆる種類のものを壊します。基本的に、聞いたことがあることを忘れてくださいsettimeofday。gettimeofday実行したいのは、測定から除外する関数の前後の両方を呼び出して、差を計算することです。次に、この関数で費やされた時間を全体の時間から除外できます。
そうは言っても、この「プロファイリング」の方法全体には大きな欠陥があります。gettimeofdayおそらく（1）測定しようとしているものと比較してかなりの時間がかかり、（2）カーネルスペースへの移行が必要になるためです。プログラムのキャッシュコヒーレンシに重大な損傷があります。この2番目の問題は、プログラムのパフォーマンス特性を観察しようとするときに、実際にそれらを変更するというもので、最も問題があります。
あなたが本当にすべきことは、この種のプロファイリング（gettimeofdayまたはgccの-pg/ gmonプロファイリング）を忘れて、代わりにoprofileまたはperfまたは同様のものを使用することです。これらの最新のプロファイリング手法は、命令ポインターとスタック情報を定期的に統計的にサンプリングすることに基づいて機能します。プログラム自体のコードはまったく変更されていないため、プロファイラーが実行されていない場合の動作に可能な限り近い動作をします。
発生している可能性がいくつかあります。1 つは、Linux が時計を正確に維持しようとすることであり、システム内で時間の感覚を滑らかに保つために、時計の調整が「スムーズ」または「修正」される可能性があります。NTP を実行している場合は、妥当な時間感覚も維持しようとします。
私のアプローチは、時計を変更するのではなく、プロセスの各部分で消費される時間を追跡することでした。高価な部分への呼び出しは累積され (入口と出口で gettimeofday の差を取得し、累積することによって)、それを全体の時間から差し引きます。より洗練されたアプローチの可能性は他にもあると思います。