Как я могу удержать большое количество вызовов OutputDebugString () от деградации моего приложения в Delphi 6 IDE?

Question

Это случалось со мной не раз и привело к потере многих часов в погоне за призраком. Как правило, когда я отлаживаю действительно сложный код, связанный с синхронизацией, я начинаю добавлять тонны вызовов OutputDebugString (), чтобы получить хорошее представление о последовательности связанных операций. Проблема в том, что Delphi 6 IDE, похоже, может так долго справляться с этой ситуацией. Я буду использовать конкретный пример, который я только что прошел, чтобы избежать обобщения (насколько это возможно).

Я потратил несколько дней на отладку кода блокировки семафоров между потоками, а также кода вычисления метки времени в DirectShow, который вызывал серьезные проблемы. После устранения каждой ошибки, о которой я только мог подумать, у меня все еще была проблема с Skype , на которую мое приложение отправляет аудио.

Примерно через 10 секунд задержка между тем, как я разговариваю и слышу мой голос, выходит из Skype на втором ПК, который я использовал для тестирования - дальний конец звонка - начал расти. Примерно через 20-30 секунд задержка начала расти экспоненциально, и в этот момент у меня появился код, который проверяет, не задерживается ли критическая секция слишком долго.

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

Таким образом, похоже, что интегрированная среда разработки Delphi 6 начинает действительно замедляться, когда объем трафика OutputDebugstring () превышает некоторый порог. Возможно, это просто задача добавления строк в панель отладчика журнала событий, которая содержит все отчеты OutputDebugString (). Я не знаю, но я видел похожие проблемы в моих приложениях, когда TMemo или аналогичный элемент управления начинает содержать слишком много строк.

Что те из вас там сделали, чтобы предотвратить это? Есть ли способ очистки журнала событий с помощью какого-либо вызова метода или хотя бы способ ограничения его размера? Кроме того, какие методы вы используете с помощью условных определений, подключаемых модулей IDE или чего-либо еще, чтобы справиться с этой ситуацией?

Answer 1

Подобная проблема случалась со мной и в Delphi 2007. Отключите просмотр событий в IDE и вместо этого используйте DebugView из Sysinternals .

Answer 2

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

Чтобы быть уверенным, я бы попытался написать простое приложение, которое просто запускается в цикле, записывая строки отладки кусками по 100 или около того, и начать запись времени, которое требуется для каждого куска, и посмотреть, не начнет ли оно увеличиваться как значительно в течение 20-30 секунд.

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

Answer 3

Я почти никогда не использую OutputDebugString. Мне сложно анализировать вывод в IDE, и требуются дополнительные усилия для сохранения нескольких наборов нескольких прогонов.

Я действительно предпочитаю хороший набор компонентов журналирования (CodeSite, SmartInspect) и обычно веду журнал для различных файлов. Например, стандартными файлами являются «Общие», «Отладка» (стандартная информация об отладке, которую я также собираю из клиентской установки), «Конфигурация», «Службы», «Клиенты». Все они настроены на «переполнение» набора пронумерованных файлов, что позволяет вам вести журналы нескольких запусков, просто добавляя больше пронумерованных файлов. Таким образом, сравнение информации журнала из разных прогонов становится намного проще.

В описываемой вами ситуации я бы добавил операторы отладки, которые ведут журнал в отдельный файл журнала. Например «Трассировка». Код для предоставления доступа к «Трассировке» находится между условными определениями. Это делает его довольно простым.

Чтобы не оставлять эти дополнительные операторы отладки, я стараюсь вносить изменения, чтобы включить журнал «Трассировка», не извлекая его из системы контроля версий. Таким образом, компилятор сервера сборки будет выбрасывать ошибки «идентификатор не определен» в любые непреднамеренно оставленные операторы. Если я хочу сохранить эти дополнительные операторы, я либо изменяю их для перехода в журнал «Отладка», либо помещаю их между условно определяет.

Answer 4

IDE Fix Pack имеет оптимизацию для повышения производительности OutputDebugString

Представление журнала отладки в IDE также получило оптимизацию.Отладчик теперь обновляет представление журнала только тогда, когда IDE не используется.Это позволяет интегрированной среде разработки реагировать, когда сотни сообщений OutputDebugString или других сообщений отладки записываются в представление журнала отладки.

Обратите внимание, что это работает только в Delphi 2007 и более поздних версиях.