Linux のプロファイリングはすべてgprofで行っていました。
ただし、私のマルチスレッドアプリケーションでは、出力に一貫性がないように見えます。
今、私はこれを掘り起こしました：
http://sam.zoy.org/writings/programming/gprof.html
ただし、それはずっと前のものであり、gprof の出力では、gprof がメイン以外のスレッドで使用される関数をリストしているようです。
だから、私の質問は次のとおりです。
貧乏人のプロファイラーを見てください。驚くべきことに、マルチスレッドアプリケーション用にCPUプロファイリングとミューテックスコンテンションプロファイリングの両方を実行するツールは他にほとんどありません。PMPは両方を実行しますが、何もインストールする必要はありません（gdbがある場合）。
ズームをご覧ください。
Valgrindをご覧ください。
ポールRは言った、ズームを見てください。lsstackを使用することもできます。これはローテクなアプローチですが、gprofと比較すると驚くほど効果的です。
追加：OpenGLを33msで実行していることを明確にしたので、私の以前の推奨事項は有効です。さらに、そのような状況で私が個人的に行ったことは、効果的で直感的ではありません。通常のワークロードまたは問題のあるワークロードで実行し、手動で停止して、実行内容と理由を確認します。これを数回行います。さて、たまにしか誤動作している場合は、誤動作している間だけ停止します。それは簡単ではありませんが、私はちょうどいい遅延のために設定された目覚まし時計の割り込みを使用しました。たとえば、100のうち1つのフレームに33ミリ秒以上かかる場合は、フレームの開始時にタイマーを35ミリ秒に設定し、フレームの終了時にオフにします。そうすれば、コードに時間がかかりすぎる場合にのみ割り込みが発生し、その理由がわかります。もちろん、1つのサンプルが有罪のコードを見逃す可能性がありますが、20のサンプルがそれを見逃すことはありません。
pstackをランダムに実行して、特定の時点でのスタックを見つけることができます。たとえば、10 回または 20 回。最も典型的なスタックは、アプリケーションがほとんどの時間を費やす場所です (経験によると、パレート分布を想定できます)。
その知識をstraceまたはtruss (Solaris) と組み合わせてシステム コールをトレースし、pmapでメモリを出力できます。
アプリケーションが専用システムで実行されている場合は、sarを使用して CPU、メモリ、I/O などを測定し、システム全体のプロファイルを作成することもできます。