Накладные расходы, связанные с OutputDebugString в сборке выпуска

Ответ 1

Измерено - звонки на 10 м занимают около 50 секунд. Я думаю, что это значительные накладные расходы для неиспользуемых функций.

Использование макроса может помочь избавиться от этого в сборке выпуска:

#ifdef _DEBUG
    #define LOGMESSAGE( str ) OutputDebugString( str );
#else
    #define LOGMESSAGE( str )
#endif

Не только удаляет вызовы, но и оценивает параметры, а текстовые строки полностью удаляются, и вы не увидите их в двоичном файле.

Ответ 2

Я пишу это после того, как на этот вопрос был дан ответ, но данные ответы не соответствуют определенному аспекту:

OutputDebugString может быть довольно быстрым, когда никто не слушает его вывод. Тем не менее, наличие прослушивателя в фоновом режиме (будь то DbgView, DBWin32, Visual Studio и т.д.) Может сделать его более чем в 10 раз медленнее (гораздо больше в среде MT). Причина, по которой эти слушатели захватывают событие отчета, и их обработка события выполняется в рамках вызова OutputDebugString. Более того, если несколько потоков вызовут OutputDebugString одновременно, они будут синхронизированы. Подробнее см. Остерегайтесь: DebugView (OutputDebugString) и Производительность.

В качестве побочного примечания, я думаю, что если вы не используете приложение реального времени, вам не следует беспокоиться о том, что для запуска 10M-вызовов требуется 50 секунд. Если ваш журнал содержит записи 10M, 50 секунд впустую - это наименьшая из ваших проблем, теперь вам нужно как-то проанализировать зверя. Журнал 10K звучит гораздо разумнее, и создание этого займет всего 0,05 секунды в соответствии с резким измерением.

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

Ответ 3

Я читал в статье, что OutPutDebugString внутренне делает несколько интересных вещей:

• Создает\Открывает мьютексы и бесконечно ждёт до получения мьютекса.
• Пропускает данные между приложением, а отладчик выполняется через 4-байтовый блок общей памяти, с Mutex и двумя объектами Event, защищающими его доступ.

Даже если отладчик не подключен (в режиме деблокирования), значительная стоимость связана с использованием OutputDebugstring с использованием различных объектов ядра.

Снижение производительности очень очевидно, если вы пишете пример кода и тест.

Ответ 4

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

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

Ответ 5

Никогда не оставляйте вызовы OutputDebugString() в сборке релиза. Всегда удаляйте их с помощью операторов #ifdef или предоставляйте другой переключатель, чтобы отключить их.

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

Theres DebugView, чтобы поймать выход приложений, но, конечно, это только хорошо, если не каждое приложение болтает без уважительной причины.

Ответ 6

Почему бы не измерить это самостоятельно? Скомпилируйте следующий код, запустите его и запустите. Затем удалите вызов OutputDebugString, перекомпилируйте и повторите попытку. Должен уйти три минуты вашего времени.

   #include <windows.h>

    int main() {
        const int COUNT = 1000000;
        int z = 0;    
        for ( unsigned int i = 0; i < COUNT; i++ ) {
            z += i;
            OutputDebugString( "foo" );
        }
        return z;
    }

Ответ 7

Мне было интересно узнать эту тему, поэтому я провел некоторое исследование.

Я опубликовал результаты, исходный код и файлы проекта, чтобы вы могли повторить тесты для своей установки. Обложки, запускающие приложение режима выпуска, ничего не отслеживая OutputDebugString, а затем с Visual Studio 6, Visual Studio 2005 и Visual Studio 2010, отслеживая OutputDebugString, чтобы узнать, какие различия в производительности для каждой версии Visual Studio.

Интересные результаты, Visual Studio 2010 обрабатывает информацию OutputDebugString до 7 раз медленнее, чем Visual Studio 6.

Полная статья здесь: Какова стоимость OutputDebugString?