为什么条件断点会降低调试时应用程序的执行速度？
当我在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
}
前面的代码比使用条件断点 (sequence == 392914) 执行得更快
When I use conditional breakpoint in VS2005 instead of using temporary code to check specific conditions, I noticed it takes more time and the execution speed is decreased!!
Do you know why? and how to resolve this issue?
Exmaple:
int sequence = atoi(m_SequenceNumber.GetAscii());
if( sequence == 392914)//temporary code to check to step into code
{
int x = 0;//I put breakpoint here
}
The previous code will execute faster than if I used conditional breakpoint with ( sequence == 392914)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
使用内存观察点比条件断点更好（如果可能）。 条件断点（正如其他人指出的那样）必须在每次执行指针经过该点时运行额外的代码，以确定它是否会中断 - 显然这需要额外的时间。 某种类型的内存观察点可以使用某些特殊的硬件寄存器 - 您可以设置多少个可以加速的观察点是有限制的，但如果您可以使用它们，则几乎没有速度损失。
使用断点窗口设置内存观察点。 您不是将其设置在一行代码上，而是设置在内存中的一个地址上。 这表明了明显的限制，它仅适用于您实际可以获取地址的内容，例如全局变量和动态分配的内存区域（使用 new 等）。 你被允许观看的内存量是有限的（基于CPU，我认为你可能会分配或多或少的特殊寄存器）。
我现在实际上并没有坐在 VS 前面，但粗略地说，您右键单击断点窗口并选择“新数据断点”之类的内容。 然后输入内存的地址和大小（以字节为单位）。 每当值发生变化时，您的观察点就会触发。 这对于解决内存损坏问题特别有用。
It is better (if possible) to use a memory watchpoint than a conditional breakpoint. A conditional breakpoint (as others have pointed out) has to run additional code each time the execution pointer goes past that point in order to determine if it would break or not - obviously this takes additional time. A memory watchpoint of a certain type gets to use certain special hardware registers - there is a limit on how many watchpoints you can set that can get accelerated, but if you can use them there is almost no speed penalty.
A memory watchpoint is set using the breakpoint window. You do not set it on a line of code, but rather on an address in memory. This suggests the obvious limitation, it only works for things you can actually take the address of, such as global variables and dynamically allocated areas of memory (using
newetc). You are limited in how much memory you are allowed to watch (based on the CPU, I think you probably get more or less special registers allocated).I'm not actually sitting in front of VS right now, but roughly speaking, you right click in the breakpoints window and choose something like "new data breakpoint". You then enter the address of the memory and the size in bytes. Whenever the value changes your watchpoint will fire. This is particularly useful for figuring out memory corruption issues.
我过去也遇到过这个问题，但从未真正找到一种方法可以在大循环中继续使用条件断点而不影响性能。 我确实了解到您可以插入一些像这样的临时代码，这不会影响性能并会导致 VS 中断（与条件断点的行为相同）。
I have run into this problem in the past as well and never really found a way to continue using Conditional Breakpoints within a large loop without affecting performance. I did learn that you could insert some temporary code like this that would not affect performance and would cause VS to break (same behavior as a Conditional Breakpoint).
考虑一下如果您正在编写调试器，将如何实现条件断点。 调试器只有在命中断点时才有机会评估条件。 因此，即使就您而言，断点是有条件的，但就处理器而言，每次执行指令时都会命中断点。 调试器获得控制权并执行以下操作：
因此，即使您从未看到断点命中（因为条件不满足），调试器可能会每秒处理断点并评估条件数千次（或者可能更多）。
Think about how you would implement a conditional breakpoint if you were writing a debugger. The only time the debugger has an opportunity to evaluate the condition is when the breakpoint is hit. So even though the breakpoint is conditional as far as you're concerned, as far as the processor is concerned the breakpoint is being hit everytime the instruction is executed. The debugger gets control and does the following:
So even if you never see the breakpoint hit (because the condition is not met), the debugger may be fielding the breakpoint and evaluating the condition thousands of times a second (or more maybe).
我认为这是因为执行条件需要时间。 它仍然比手动步进必要的次数要快得多。
I assume it is because it takes time to execute the condition. It is still a lot faster than manually stepping the necessary number of times tough.
添加的临时代码可以由编译器优化（至少一点点）。
条件断点可能会跳转到一些 Visual Studio 代码，这些代码将手动检索所需的信息以了解它是否确实需要暂停。
这可以在某种程度上解释为什么需要更多时间。
但我只是猜测。
Added temporary code can be optimized (at least a bit) by the compiler.
Conditional breakpoint probably jumps to some visual studio code that will manually retrieve needed information to know whether it actually has to pause or not.
That would somehow explain why it takes more time.
But i am just guessing.