Почему условная точка останова снижает скорость выполнения приложения во время отладки?

Question

Когда я использую условную точку останова в VS2005 вместо временного кода для проверки конкретных условий, я заметил, что это занимает больше времени и скорость выполнения уменьшается !! Ты знаешь почему? и как решить эту проблему?

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
    }

Предыдущий код будет выполняться быстрее, чем если бы я использовал условную точку останова с (sequence == 392914)

Answer 1

Лучше (если возможно) использовать контрольную точку памяти, чем условную контрольную точку. Условная точка останова (как уже указывали другие) должна запускать дополнительный код каждый раз, когда указатель выполнения проходит эту точку, чтобы определить, будет ли он сломан или нет - очевидно, это требует дополнительного времени. Точка наблюдения за памятью определенного типа получает возможность использовать определенные специальные аппаратные регистры - существует ограничение на количество точек наблюдения, которые вы можете установить для ускорения, но если вы можете их использовать, штраф за скорость почти отсутствует.

Точка наблюдения за памятью устанавливается с помощью окна точки останова. Вы устанавливаете его не на строку кода, а на адрес в памяти. Это предполагает очевидное ограничение, оно работает только для вещей, адрес которых вы можете фактически использовать, таких как глобальные переменные и динамически выделенные области памяти (используя new и т. Д.). Вы ограничены в том, сколько памяти вам разрешено наблюдать (исходя из процессора, я думаю, вы, вероятно, получите более или менее специальные регистры).

На самом деле я сейчас не сижу перед VS, а грубо говоря, вы щелкаете правой кнопкой мыши в окне точек останова и выбираете что-то вроде «новой точки останова данных». Затем вы вводите адрес памяти и размер в байтах. Всякий раз, когда значение меняется, ваша точка наблюдения будет срабатывать. Это особенно полезно для выяснения проблем повреждения памяти.

Answer 2

Подумайте, как бы вы реализовали условную точку останова, если бы писали отладчик. Единственный раз, когда отладчик имеет возможность оценить условие, это когда достигается точка останова. Таким образом, даже если точка останова является условной для вас, то, что касается процессора, точка останова срабатывает при каждом выполнении инструкции. Отладчик получает управление и выполняет следующие действия:

• определяет, что точка останова является условной
• оценивает выражение
• если выражение ложно, отладчик продолжает выполнение
• в противном случае отладчик передает вам управление

Таким образом, даже если вы никогда не увидите попадание в точку останова (потому что условие не выполнено), отладчик может выставить точку останова и оценивать условие тысячи раз в секунду (или, возможно, больше).

Answer 3

Я сталкивался с этой проблемой и в прошлом и так и не нашел способа продолжать использовать условные точки останова в большом цикле, не влияя на производительность. Я узнал, что вы можете вставить некоторый временный код, подобный этому, который не повлияет на производительность и приведет к сбою VS (такое же поведение, как и для условной точки останова).

if ( condition ) Debugger.Break();

Answer 4

Добавленный временный код может быть оптимизирован (хотя бы немного) компилятором. Условная точка останова, вероятно, переходит к некоторому визуальному студийному коду, который будет вручную извлекать необходимую информацию, чтобы знать, должна ли она фактически быть приостановлена ​​или нет.

Это как-то объясняет, почему это занимает больше времени. Но я просто догадываюсь.

Answer 5

Я предполагаю, что это потому, что для выполнения условия требуется время. Это все еще намного быстрее, чем вручную делать необходимое количество раз.