Visual Studio - Влияние времени выполнения условных и отключенных точек останова

Question

Потратив немного времени, задаваясь вопросом, почему мое приложение очень медленно запускало конкретный сценарий с прикрепленным отладчиком, я обнаружил, что это было связано с условной точкой останова (чье состояние никогда не было выполнено). Это кажется разумным, поскольку ЦП будет сигнализировать о точке останова, а VS должен будет оценить условие, прежде чем позволить выполнять продолжение. Эти переходы должны быть дорогостоящими.

Я предполагаю, что точка останова в пути кода, который не выполняется, не оказывает воздействия времени выполнения.

Итак, мой вопрос дважды:

1. Существуют ли какие -либо ресурсы, которые могут количественно оценить стоимость, связанные с условными точками останова, и если это так, может ли что -нибудь сделать, чтобы снизить стоимость оценки их времени выполнения?
2. Есть ли какая -либо затраты, связанная с точкой перерыва отключений? Под отключением я имею в виду, что VS отображает маркер точки останова в желобе с полым кругом.

Конечно, если что -то, что я упоминал выше, не имеет смысла, тогда укажите мне правильное направление.

Answer 1

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

Однако я могу перечислить несколько вещей, которые, как известно, медленнее в окне отладки

• Функциональные вызовы: они самая медленная вещь, которую вы можете сделать, потому что функциональный вызов требует, чтобы процесс отладки был перезагружен, чтобы Func Eval могла произойти в процессе
• Сравнение струн: под капотом они возвращаются к фан -эвалям

Что касается отключенных точек останова, нет, они не влияют на запуск приложения.

Answer 2

Одна вещь, за которой нужно следить (что я узнал трудным способом) - это убедиться, что вы положили == при сравнении переменной с значением, а не синглом =

Редактор точки останова не предупреждает вас, но когда точка останова оценена, переменная изменена! Мне потребовалось некоторое время, чтобы отлаживать мой код с этим!

Кроме того, если мне действительно нужна условная точка останова для кода Bebug; Я добавляю условие в код, затем добавляю что -то вроде String Stop = "здесь"; И поместите там нормальную точку останова - я нахожу, что код работает быстрее.

Answer 3

Я прочитал, что есть аппаратная поддержка для этих точек останова, так что использование менее чем x условных точек останова определенного вида, по сути, бесплатно, но выше, он должен использовать больше программного обеспечения. (OTOH, это было для местных приложений, не уверенных в этих новых вещах JIT.)

Точки отключения отключений должны повлиять на вещи вообще, они просто закопают некоторые память и ресурсы GUI в IDE.

Answer 4

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

То, что я делаю, когда я нахожусь в такой ситуации, как ваша, так это создать макрос Assert. (Вы можете использовать утверждать Макро, который предоставляет Visual Studio, но мне это не нравится). Пусть ваш макрос проверьте желаемое состояние, а затем позвоните Отладка Если это терпит неудачу. В сфере Sealrease или без проверки вашего приложения Assert оценивает ничто, поэтому ваш код не влияет.

Простой макрос Assert может выглядеть как:

#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 Чтобы адаптировать ваше утверждение еще больше. Мне также нравится использовать формат строки &&, чтобы дать немного больше информации о конкретной утверждении.

Есть несколько вещей, которые нужно осторожнее при использовании Assert. Во -первых, не размещайте код, который должен быть запущен в макросе, так как он будет разбросан в не докладе. По тем же причинам не вкладывайте код, который имеет побочные эффекты. Кроме того, вы не хотите вызывать DebugBreak (), когда отладчик не прилагается, потому что он по существу бросает исключение, которое, если не поймано, прекратит приложение.

Answer 5

1. Попробуйте поместить точку останова в коде, чтобы проверить производительность. НАПРИМЕР

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

   Нет, не совсем то же самое, но достаточно близко.

2. Нет - отключенная точка останова не присутствует в программе выполнения. Он просто хранится в метаданных VS для вашего удобства.