イベント効率

デバッグ中のプログラムの実行時間に関するオーバーヘッドの量はイベントの種類によって異なります。もっとも単純なブレークポイントのように、実際はオーバーヘッドが何もないイベントもあります。1 つのブレークポイントしかないイベントも、オーバーヘッドは最小です。

実際のブレークポイントがときには何百にもなることのある多重ブレークポイント (inclass など) は、コマンド発行時にのみオーバーヘッドがあります。これは、dbx が永続的ブレークポイントを使用するためです。永続的ブレークポイントは、プロセスに常に保持され、停止するたびに取り除かれたり、cont コマンドのたびに置かれたりすることはありません。

step コマンドおよび next コマンドの場合、デフォルトでは、プロセスが再開される前にすべてのブレークポイントが取り除かれ、ステップが完了するとそれらは再び挿入されます。したがって、多くのブレークポイントを使用したり、多くのクラスで多重ブレークポイントを使用したりしているとき、step コマンドおよび next コマンドの速度は大幅に低下します。dbx step_events 環境変数を使用して、各 step コマンドまたは next コマンドのあとにブレークポイントを取り出して再挿入するかどうかを制御します。

自動ステップ実行を利用するイベントはもっとも低速です。これは、各ソース行をステップ実行する単純な trace step コマンドの場合と同様にはっきりしています。一方、stop change expression や trace cond variable のようなイベントは、自動的にステップ実行するだけでなく、各ステップで式や変数を評価する必要があります。

これらのイベントは非常に低速ですが、イベントと修飾語 -in を使用した関数とを結び付けることで、効率が上がることがよくあります。次に例を示します。

trace next -in mumble
stop change clobbered_variable -in lookup

trace -in main を使用しないでください。これは main によって呼び出された関数の中でも、trace が有効になるためです。関数 lookup() が変数の値を頻繁に変更すると思われる場合には、この方法を使用してください。