gprof でプロファイリングしたいプログラムがあります。問題は (一見) ソケットを使用していることです。だから私はこのようなものを得ます：
::select(): Interrupted system call
私はしばらく前にこの問題にぶつかり、あきらめて先に進みました。しかし、可能であれば gprof を使用して、自分のコードをプロファイリングできるようにしたいと考えています。私に何ができる？不足している gprof オプションはありますか? ソケットオプション？これらのタイプのシステムコールが存在する場合、gprof はまったく役に立たないのですか? もしそうなら、実行可能な代替手段はありますか？
編集:プラットフォーム:
ソケット コードは、プロファイラーに関係なく中断されたシステム コールを処理する必要がありますが、プロファイラーの下では避けられません。これは、次のようなコードを持つことを意味します。
if ( errno == EINTR ) { ...
各システムコールの後。
たとえば、背景についてはこちらをご覧ください。
gprof ( here's the paper ) は信頼できますが、変更を測定することのみを目的としており、そのためにも、CPU バウンドの問題のみを測定します。問題の特定に役立つと宣伝されたことはありません。それは他の人がその上に重ねたアイデアです。
この方法を検討してください。
いくらかのお金を使うことを厭わないなら、別の良いオプションはZoomです。
追加：例を挙げることができれば。Main が A を何回か呼び出し、A が B を何回か呼び出し、B が C を何回か呼び出し、C がソケットまたはファイルで I/O を待機する呼び出し階層があるとします。プログラムはそうします。さらに、各ルーチンが次のルーチンを呼び出す回数が、実際に必要な回数よりも 25% 多いとします。1.25^3 は約 2 であるため、プログラム全体の実行には実際に必要な時間の 2 倍の時間がかかることになります。
そもそも、すべての時間は I/O の待機に費やされているため、gprof は「実行中」の時間しか見ていないため、その時間がどのように費やされているかについて何も教えてくれません。
次に、(議論のために) I/O 時間をカウントしたとします。基本的に、各ルーチンに 100% の時間がかかることを示すコール グラフが得られます。それはあなたに何を伝えますか？あなたがすでに知っている以上のものはありません。
ただし、少数のスタック サンプルを取得すると、それらのすべてに、各ルーチンが次のルーチンを呼び出すコード行が表示されます。つまり、大まかな時間の見積もりを提供するだけでなく、コストのかかる特定のコード行を示しています。コードの各行を見て、回数を減らす方法がないか尋ねることができます。これを行うと仮定すると、2 倍のスピードアップが得られます。
人々はこのようにして大きな要因を獲得します。私の経験では、呼び出しレベルの数は簡単に 30 以上になります。回避できるかどうかを尋ねるまで、すべての呼び出しが必要に思えます。少数の回避可能な呼び出しでさえ、その多くのレイヤーに大きな影響を与える可能性があります。