Visual Studio-条件付きおよび障害のあるブレークポイントのランタイムインパクト

StackOverflow https://stackoverflow.com/questions/1589510

質問

デバッガーが添付されているときに、なぜ私のアプリが特定のシナリオを非常にゆっくり実行しているのか疑問に思って少し時間を費やした後、これは条件付きブレークポイント（その状態が満たされていない）があるためであることを発見しました。これは、CPUがブレークポイントを知らせ、VSが実行を続行する前に状態を評価する必要があるため、合理的に思えます。これらの遷移は費用がかかる必要があります。

実行されていないコードパスのブレークポイントには、ランタイムインパクトがないと思います。

だから私の質問は2つあります：

  1. 条件付きブレークポイントに関連するコストを定量化できるリソースはありますか？もしそうなら、ランタイム評価コストを削減するためにできることはありますか？
  2. 「無効」ブレークポイントに関連するコストはありますか？無効にすることで、VSは中空の円で溝にブレークポイントマーカーを表示することを意味します。

もちろん、上記のことが意味をなさない場合は、正しい方向に向かってください。

役に立ちましたか？

解決

条件付きブレークポイントのコストを定量化することは困難です。条件付きブレークポイントの式は、まったく同じセマンティクスを使用して評価されます。この性質の表現は、実際にクライアントプログラムで実行されるのではなく、言語固有の式評価者によって処理されます。これらのタイプの評価を意味のある方法でプロファイルすることは実際には不可能です。

ただし、デバッグウィンドウの評価で遅くなることが知られているいくつかのものをリストできます

  • 関数呼び出し：関数呼び出しでは、Debuggeeプロセスを再起動する必要があるため、プロセス内でFUNC評価が発生する可能性があるため、これらはできる最も遅いことです。
  • 文字列比較：フードの下で、これらはfuncevalsに戻ります

無効なブレークポイントに関しては、それらはアプリケーションの実行に影響しません。

他のヒント

注意すべきことの1つ（私は難しい方法を学んだ）は、変数を単一=ではなく値と比較するときに==を確実に入力することです。

ブレークポイントエディターは警告しませんが、ブレークポイントが評価されると、変数が変更されます！コードでコードをデバッグするのにしばらく時間がかかりました！

また、コードをbugするには条件付きブレークポイントが本当に必要な場合。条件をコードに追加してから、文字列stop = "Here"のようなものを追加します。そこに通常のブレークポイントを置いてください - コードがより速く実行されることがわかります。

これらのブレークポイントにはハードウェアサポートがあるため、特定の種類のXより少ない条件付きブレークポイントを使用することは本質的に無料ですが、それ以上にソフトウェアを使用する必要があることをSomewhereで読みました。 （Otoh、それはネイティブアプリ向けでしたが、これらの新しいJITのことについてはわかりません。）

無効なブレークポイントは、物事に影響を与えるはずです。IDEのメモリとGUIのリソースをいくつかオコープします。

また、条件付きブレークポイントが高価であることに気づき、あなたと同じ結論に達しました。障害のあるブレークポイントが編集者のみであると予想されるため、スローダウンを引き起こす理由は想像できません。

私があなたのような状況にいるときに私がしていることは、アサートマクロを作ることです。 （使用できます 主張する ビジュアルスタジオが提供するマクロですが、私はそれが好きではありません）。マクロにあなたが望む状態をチェックさせてから電話してください デバッグブレイク 失敗した場合。アプリケーションのRealeaseまたは非チェックビルドでは、何も評価されていないと主張するため、コードは影響を受けません。

単純なアサートマクロは次のように見えます。

#ifdef _DEBUG
#define assert(x)\
do{\
  if(!(x)){DebugBreak();}\
}while(0)
#else
#define assert(x)
#endif

そして、それを次のように呼びます：

assert(pValue != NULL && "A bad parameter was passed to the function");

デバッグブレイクの前に、より多くのコードを失敗に配置することができます（＃xで失敗した条件や____File____および____LINE____で行/ファイル番号を印刷するなど、メッセージをダブルクリックできます）。デバッグログにメッセージを書くことができます outputdebugstring デバッガーが添付されているかどうかを確認することも確認してください isdebuggerpresent あなたのアサートをさらに調整するために。また、&&文字列形式を使用して、特定のアサートに関するもう少し情報を提供するのが好きです。

アサートを使用するときに注意すべきことがいくつかあります。まず、マクロで実行する必要があるコードを入れないでください。非デバッグビルドで剥がれます。同じ理由で、副作用があるコードを入れないでください。また、デバッガーが添付されていない場合、DebugBreak（）を呼び出したくありません。

  1. パフォーマンスをテストするために、コードにブレークポイントを置いてみてください。例えば

    Stopwatch st = new Stopwatch();
st.Start();
if(my condition)
{
  st.Stop();
  Debugger.Break();
}

    いいえ、まったく同じではありませんが、十分に近いです。

  2. いいえ - 実行プログラムには無効なブレークポイントが存在しません。便利なためにVSメタデータに保管されています。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top