イベント効率

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

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

step コマンドおよび next コマンドの場合、デフォルトでは、プロセスが再開される前にすべてのブレークポイントが取り除かれ、ステップが完了するとそれらは再び挿入されます。したがって、多くのブレークポイントを使用したり、多くのクラスで多重ブレークポイントを使用したりしているとき、step コマンドおよび next コマンドの速度は大幅に低下します。dbxenv 変数 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 によって呼び出された関数の中でも、トレースが有効になるためです。関数 lookup() が変数の値を頻繁に変更すると思われる場合には、この方法を使用してください。