7

一時的なコードを使用して特定の条件をチェックする代わりに、VS2005で条件付きブレークポイントを使用すると、時間がかかり、実行速度が低下することに気付きました。なぜなのかご存知ですか？そしてこの問題を解決する方法は？

例：

    int sequence = atoi(m_SequenceNumber.GetAscii());
    if( sequence == 392914)//temporary code to check to step into code
    {
        int x = 0;//I put breakpoint here
    }

前のコードは、（シーケンス== 392914）で条件付きブレークポイントを使用した場合よりも高速に実行されます

4

5 に答える 5

4

(可能であれば) 条件付きブレークポイントよりもメモリ ウォッチポイントを使用することをお勧めします。条件付きブレークポイント (他の人が指摘したように) は、ブレークするかどうかを判断するために、実行ポインターがそのポイントを通過するたびに追加のコードを実行する必要があります。これには明らかに時間がかかります。特定のタイプのメモリ ウォッチポイントは、特定の特別なハードウェア レジスタを使用します。設定できるウォッチポイントの数には制限がありますが、それらを使用できれば、速度の低下はほとんどありません。

メモリ ウォッチポイントは、ブレークポイント ウィンドウを使用して設定されます。コード行ではなく、メモリ内のアドレスに設定します。これは明らかな制限を示唆しています。これは、グローバル変数や動的に割り当てられたメモリ領域 (などを使用) など、実際にアドレスを取得できるものに対してのみ機能しますnew。監視できるメモリの量が制限されています（CPUに基づいて、おそらく多かれ少なかれ特殊レジスタが割り当てられると思います）。

私は実際に VS の前に座っているわけではありませんが、大まかに言えば、ブレークポイント ウィンドウを右クリックして、「新しいデータ ブレークポイント」などを選択します。次に、メモリのアドレスとサイズをバイト単位で入力します。値が変化するたびに、ウォッチポイントが起動します。これは、メモリ破損の問題を把握するのに特に役立ちます。

于 2009-02-11T07:52:49.087 に答える
3

私も過去にこの問題に遭遇しましたが、パフォーマンスに影響を与えずに大きなループ内で条件付きブレークポイントを使用し続ける方法を実際に見つけたことはありませんでした。このような一時的なコードを挿入すると、パフォーマンスに影響を与えず、VS が壊れる可能性があることを知りました (条件付きブレークポイントと同じ動作)。

if ( condition ) Debugger.Break();
于 2009-02-11T08:07:43.950 に答える
2

デバッガーを作成する場合、条件付きブレークポイントをどのように実装するかを考えてください。デバッガーが条件を評価する機会があるのは、ブレークポイントに到達したときだけです。したがって、ブレークポイントは条件付きですが、プロセッサに関する限り、命令が実行されるたびにブレークポイントがヒットします。デバッガーは制御を取得し、次のことを行います。

  • ブレークポイントが条件付きであると判断する
  • 式を評価します
  • 式がfalseの場合、デバッガーは実行を続行します
  • それ以外の場合、デバッガーは制御をユーザーに渡します

したがって、ブレークポイントがヒットしたことがない場合でも（条件が満たされていないため）、デバッガーはブレークポイントをフィールド化し、1秒間に数千回（またはそれ以上）条件を評価している可能性があります。

于 2009-02-11T09:02:26.517 に答える
0

条件の実行に時間がかかるためだと思います。必要な回数だけ手動で踏むよりもはるかに高速です。

于 2009-02-11T07:35:42.483 に答える
0

追加された一時コードは、コンパイラによって (少なくとも少しは) 最適化できます。条件付きブレークポイントはおそらく、実際に一時停止する必要があるかどうかを知るために必要な情報を手動で取得するビジュアル スタジオ コードにジャンプします。

それはどういうわけかそれがより多くの時間がかかる理由を説明するでしょう. しかし、私はちょうど推測しています。

于 2009-02-11T07:45:29.230 に答える