デバッグ中のプログラムの実行時間に関するオーバーヘッドの量はイベントの種類によって異なります。もっとも単純なブレークポイントのように、実際はオーバーヘッドが何もないイベントもあります。1 つのブレークポイントしかないイベントも、オーバーヘッドは最小です。
inclass など数百のブレークポイントになる可能性のある複数のブレークポイントは、作成時にのみオーバーヘッドがあります。dbx は永続的ブレークポイントを使用しますが、それらはプロセスに常に保持され、停止するたびに取り除かれたり、cont コマンドのたびに置かれたりすることはありません。
step コマンドおよび next コマンドの場合、デフォルトでは、プロセスが再開される前にすべてのブレークポイントが取り除かれ、ステップが完了するとそれらは再び挿入されます。したがって、多くのブレークポイントを使用したり、多くのクラスで多重ブレークポイントを使用したりしているとき、step コマンドおよび next コマンドの速度は大幅に低下します。dbx step_events 環境変数を使用して、各 step コマンドまたは next コマンドのあとにブレークポイントを取り出して再挿入するかどうかを制御します。
もっとも低速なイベントは、自動ステップ実行を使用するイベントです。このプロセスは、各ソース行をステップ実行する trace step コマンドと同様に、明示的で明確です。stop change や trace cond のようなその他のイベントは、自動的にステップ実行するだけでなく、各ステップで式や変数を評価する必要もあります。
これらのイベントは非常に低速ですが、イベントと修飾語 -in を使用した関数とを結び付けることで、効率が上がることがよくあります。例:
trace next -in mumble stop change clobbered_variable -in lookup
trace -in main は使用しないでください。trace は main によって呼び出された関数の中でも有効であるためです。lookup() 関数が変数を破壊していることが疑われる場合に、この修飾子を使用します。