Как я могу узнать источник длительных задержек при изменении размера основной формы?

Question

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

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

Очевидно, я не ожидаю, что кто-нибудь укажет мне на какой-то ошибочный фрагмент кода, но я после отладки подходов, которые могут мне помочь. У меня есть обширный код времени выполнения во всем приложении, и большие задержки не отображаются ни в одной из данных. Например, время выполнения основного обработчика формы OnResize минимально.

Answer 1

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

Answer 2

OK.Задача решена.Я заметил, что проблема возникала только тогда, когда у меня были включены ключи командной строки для записи некоторой отладочной информации.Информация об отладке включала некоторые ответы HTTP, которые были записаны в журнал отладки (TMemo) на одной из вкладок.Когда HTTP-ответ включал большой блок без CR / LF, TMemo обернул его.Всякий раз, когда я изменял размер главной формы, TMemo изменял размер, и элемент управления должен был снова отображать текст с новым переносом слов.

Чтобы продемонстрировать:

• начать новый проект Delphi
• перетащите TMemo на форму
• выровняйте его по клиенту
• скомпилируйте и запустите
• вставьте большой объем текста в TMemo
• измените размер основной формы

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

BTW @Mason - подхватит ли это SamplingProfiler - учитывая, что выполнение находится внутри VCL, а не в моем коде?

Answer 3

Запустите ваше приложение в профилировщике производительности AQTime (входит в XE, но вы можете получить ограниченную по времени версию на их веб-сайте).

Сделайте некоторое фанатическое изменение размера некоторое время, а затем остановите приложение.

После этого вы увидите, какая именно функция была вызвана много раз и где было потрачено больше времени.

Answer 4

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

Может возникнуть ситуация, когда элементы управления сталкиваются друг с другом, отключая каскадные события изменения размера. Как трое братьев и сестер на заднем сиденье компактного автомобиля, когда они начинают бороться за свое положение, им может понадобиться некоторое время, чтобы «успокоиться».

Не заставляй меня переворачивать эту машину ...

Журнал отладки (видимый в IDE или с помощью внешнего средства просмотра ODS) может показать, какие из них вызывают наибольшую проблему, если они появляются несколько раз для одного «инициированного пользователем события изменения размера».