为什么条件断点会在调试时降低应用程序执行速度?

时间:2009-02-11 07:32:26

标签: visual-studio debugging conditional-breakpoint

当我在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)

的速度要快

5 个答案:

答案 0 :(得分:4)

使用内存观察点比使用条件断点更好(如果可能)。条件断点(正如其他人指出的那样)必须在每次执行指针超过该点时运行附加代码,以确定它是否会中断 - 显然这需要额外的时间。某种类型的内存观察点可以使用某些特殊的硬件寄存器 - 您可以设置多少可以加速的观察点,但如果您可以使用它们几乎没有速度惩罚。

使用断点窗口设置内存观察点。您不是在代码行上设置它,而是在内存中的地址上设置它。这表明存在明显的局限性,它仅适用于您可以实际获取地址的内容,例如全局变量和动态分配的内存区域(使用new等)。您可以观看多少内存(基于CPU,我认为您可能会获得或多或少的特殊寄存器)。

我现在并没有真正坐在VS前面,但粗略地说,你在断点窗口右键单击并选择“新数据断点”之类的东西。然后输入内存的地址和大小(以字节为单位)。每当值发生变化时,您的观察点就会触发。这对于解决内存损坏问题特别有用。

答案 1 :(得分:2)

我过去也遇到过这个问题,并且从未真正找到过在大循环中继续使用条件断点而不影响性能的方法。我确实知道你可以插入一些这样的临时代码,这些代码不会影响性能并导致VS中断(与条件断点相同的行为)。

if ( condition ) Debugger.Break();

答案 2 :(得分:2)

考虑在编写调试器时如何实现条件断点。调试器有机会评估条件的唯一时间是命中断点。因此,就您而言,断点是有条件的,就处理器而言,每次执行指令时都会触发断点。调试器获得控制权并执行以下操作:

  • 确定断点是有条件的
  • 评估表达式
  • 如果表达式为false,则调试器继续执行
  • 否则,调试器会将控制权交给您

因此,即使您从未看到断点被击中(因为条件不满足),调试器可能会使用断点并每秒数次(或更多)评估条件。

答案 3 :(得分:0)

我认为这是因为执行条件需要时间。它比手动踩踏必要的次数还要快很多。

答案 4 :(得分:0)

添加的临时代码可以由编译器优化(至少一点)。 条件断点可能跳转到某些可视化工作室代码,该代码将手动检索所需信息以确定它是否实际上必须暂停。

这会以某种方式解释为什么需要更多时间。 但我只是在猜测。