2 番目の方法は、本質的にスタック サンプリングです。なんらかの入口と出口のイベント キャプチャを使用して、自分で実行することもできます。または、実際にスタックを読み取るユーティリティがあればよりよいでしょう。後者には、メソッド レベルだけでなく、コード行の解決が得られるという利点があります。
多くの人がこれについて理解していないことがあります。それは、タイミング測定の精度は問題識別の精度よりもはるかに重要ではないということです。
I/O やその他のブロッキング中でもサンプルを取得することが重要です。これにより、不必要な I/O が見えなくなることはありません。他のプロセスとの競合によって時間が過大になるのではないかと心配している場合でも、気にしないでください。本当に重要なのは絶対的な時間の測定値ではなく、パーセンテージです。たとえば、コードの 1 行が実時間の 50% スタック上にある場合、それを取り除くと、他に何が起こっているかに関係なく、アプリの速度が 2 倍になります。
プロファイリングは、サンプルを取得するだけではありません。多くの場合、人々は自分が何をするかについてかなりカジュアルですが、そこにお金があります. まず、包含時間は、メソッドまたはコード行がスタック上にある時間の割合です。「自己」時間は忘れてください - それは包括的な時間に含まれています。呼び出しのカウントを忘れてください。包括的パーセントとの関係は、せいぜい非常に間接的です。要約する場合、コードの 1 行に焦点を当てた「バタフライ ビュー」を作成するのが最善の方法です。その左右には、スタック サンプルのすぐ上とすぐ下に表示されるコード行があります。コードの各行の横にはパーセント (そのコード行を含むスタック サンプルのパーセント) があります。(そして、再帰について心配する必要はありません。単純に問題ではありません。)
どんな種類の要約よりも優れているのは、スタック サンプル自体の小さなランダムな選択をユーザーに表示させることです。そうすれば、ユーザーは、各スナップショットが費やされた理由の全体像を把握できます。複数のサンプルに表示される回避可能なアクティビティは、大幅な高速化のチャンスであり、保証されています。人々はしばしば「まあ、それは本当のボトルネックではなく、まぐれかもしれない」と考えます。そうではありません。それを修正すると、おそらく少し、おそらく多くの利益が得られますが、平均して-重要です。人々はリスク回避によって支配されるべきではありません。
そのすべてについてもっと。