Schumi が言ったように、pstack のようなものを使用してスタック サンプルを取得できます。ただし、実際に知っておく必要があるのは、サンプルが取得された時点でプログラムが時間を費やしている理由です。関数名のスタックだけからそれを理解できるかもしれません。呼び出しが発生したコード行も確認できるとよいでしょう。引数の値とデータ コンテキストを確認できればなおさらです。その理由は、「ホット スポット」、「遅い方法」、「ボトルネック」、つまり測定ベースの視点を探しているという一般的な概念とは対照的に、探すべき最も価値のあることは、排除できる可能性があることです。
つまり、デバッガーでプログラムを停止するときは、それが何をしているのかをバグであるかのように考えてください。そのようなことをしない方法を見つけてみてください。ただし、別のサンプルを取得して同じことを確認するまで、これを実行しないでください。ただし、そのことを説明します。これで、かなりの時間がかかっていることがわかります。どのくらいの時間?それは問題ではありません。修正後にわかります。あなたはそれがたくさんあることを知っています。2 回見る前に取得する必要のあるサンプルが少ないほど、サイズが大きくなります。
次に「拡大効果」です。その「速度バグ」を修正すると、プログラムの所要時間が大幅に短縮されますが、それだけではありません。他にもありますが、今ではより多くの時間を費やしています。だから、もう一度やり直してください。これを終える頃には、プログラムがおもちゃよりも大きい場合、その速さに驚かれることでしょう。
これは 43 倍のスピードアップです。
これは730倍のスピードアップです。
これがその背後にある退屈な数学です。
おわかりのように、ツールの問題は、サンプリングの容易さに対して代償を払っていることです。あなたはそれを測定と考えているので、コードが何をしているのかという理由、つまり疑わしい理由に集中していません。これにより、コードを高速化する機会を逃し、拡大効果を見逃すことになり、最終的に可能な高速化のはるか手前で停止することになります。
編集:炎の謝罪。あなたの質問に答えるために、私はコンパイラの最適化を最後までオンにしません。これは、より大きな問題を隠す可能性があるためです。次に、最適化がオンになっているビルドを実行しようとしますが、シンボリック情報が残っているため、デバッガーは妥当なスタック トレースを取得して変数を調べることができます。スピードアップのリターンが減少している場合は、全体の時間を測定するだけで、オプティマイザーがどれだけの違いをもたらしたかがわかります。そのためのプロファイラーは必要ありません。