__gnu_mcount_nc を使用する以外に、パフォーマンス プロファイリングで関数の終了時間を正確に測定するにはどうすればよいでしょうか?

__gnu_mcount_nc を使用した関数終了時間の決定

組み込みプラットフォームでパフォーマンス プロファイリングを実行しようとすると、GCC の - pg フラグは、すべての関数への入り口で __gnu_mcount_nc にサンクを挿入します。 __gnu_mcount_nc の実装はすぐに利用できませんが、スタック フレームと現在のサイクル数を記録するカスタム実装は、呼び出し元/呼び出し先グラフを収集し、頻繁に呼び出される関数を特定するのに役立つことが証明されています。

ただし、内部で費やされた時間に関する情報を取得することはできません。関数本体は、エントリ ポイントのみに基づいた課題のままです。シャドウ コールスタックの維持やリターン アドレスの操作などの既存のアプローチでは、制限とオーバーヘッドが生じます。

関数の終了時間のキャプチャを可能にする代替の __gnu_mcount_nc 実装の問題に対処するために、で使用される実際のアプローチを詳しく調べてみましょう。 gprof.

gprof の関数の測定方法Time

当初の想定に反して、gprof は関数の開始または終了のタイミングに __gnu_mcount_nc を使用しません。代わりに、各ルーチンで PC サンプルをカウントすることによって収集された自己時間を利用します。これらのサンプルは、関数間の呼び出し数とともに使用され、呼び出し元に帰すべきセルフタイムの部分を推定します。

呼び出しカウントとスタック サンプリング

もう 1 つのアプローチはスタック サンプリングです。これには、一定の間隔でスタックのサンプルをキャプチャすることが含まれます。 PC サンプリングよりも高価ですが、短い呼び出しと長い呼び出しを区別せず、I/O や計測されていないライブラリ ルーチンの影響を受けないため、より正確な測定が可能です。

コストのかかる操作の特定

パフォーマンスのボトルネックを見つける鍵は、生のスタック サンプルを分析し、ソース コードに関連付けることにあります。コール グラフやホットスポットに焦点を当てるのとは対照的に、個々のスタック サンプルを調査すると、特定の操作で時間がかかる具体的な理由が明らかになり、考えられる最適化が提案されます。

派手な視覚化を超えて

フレーム グラフやツリー マップなどのビジュアライゼーションは視覚的に魅力的ですが、異なる場所から何度も呼び出されるコードに起因するパフォーマンスの問題を強調できないことがよくあります。時間のみに基づいてデータを集計するのではなく、関数ごとにデータを集計および並べ替えることで、コード実行のより包括的なビューが提供されます。

結論

__gnu_mcount_nc は関数のエントリ ポイントに関する貴重な情報を提供しますが、関数の終了時間をキャプチャするにはスタック サンプリングなどの代替方法を考慮する必要があります。実際のスタック サンプルの分析に集中し、目を引く視覚化から気が散ることを避けることで、開発者はパフォーマンスのボトルネックを効果的に特定し、最適化を実装できます。

以上が__gnu_mcount_nc を使用する以外に、パフォーマンス プロファイリングで関数の終了時間を正確に測定するにはどうすればよいでしょうか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。