この出力結果からは、このプログラムの実行時間のほとんどは compare_strings ルーチンに費やされ、次に、_strlen ライブラリルーチンに費やされていることがわかります。このプログラムを改良するためには、compare_strings 関数に専念する必要があります。
それでは次に、このプロファイリング実行結果を解読していきます。結果は以下の列見出しの下に一覧表示されます。
%Time -- プログラムのこのルーチンによって消費される CPU 時間の合計におけるパーセンテージ。
Seconds -- この関数によって占められる CPU 時間の合計。
Cumsecs -- この関数およびその上位にリストされている関数によって占められる CPU 時間の総合計 (秒) 。
#Calls -- このルーチンが呼び出される回数。
msecs/call -- このルーチンが呼び出されるたびに消費する平均ミリ秒数。
Name -- ルーチンの名前
このプロファイルデータからはいったいどんな結果が導き出されるのでしょうか。compare_strings 関数は、プログラムの総時間の約 20 パーセントを消費しています。そこで、この index.assist を改良するには、compare_strings が使用しているアルゴリズムを改良するか、compare_strings の呼び出し回数を減らすという方法が考えられます。
このフラットコールグラフからは compare_strings がかなり強い再帰性を持つかはわかりませんが、次の項で説明するコールグラフプロファイルを利用することによって、こうした情報も得ることができます。ここで紹介しているケースの場合は、アルゴリズムの改良によって呼び出し回数も減少します。
Solaris オペレーティング環境のバージョン 2.6 および 7 では、複数の CPU を使用するプログラムに対して CPU 時間のプロファイルは正確ですが、カウントはロックされていないため、関数のカウントの正確さには影響があるかもしれません。