Как я могу узнать источник длительных задержек при изменении размера основной формы?
У меня есть приложение D2006, которое содержит элемент управления страницы и различные сетки и т. Д. На вкладках. Когда я изменяю размер основной формы (которая пронизывает и изменяет размер практически всего в форме, которая соответствует чему-либо), я испытываю длительные задержки, например, несколько секунд. Приложение зависает, неактивный обработчик не вызывается, и запущенные потоки, похоже, также приостанавливаются.
Я пытаюсь приостановить выполнение в IDE, пока это происходит, пытаясь прервать выполнение, пока оно находится в проблемном коде, но IDE не принимает сообщения.
Очевидно, я не ожидаю, что кто-нибудь укажет мне на какой-то ошибочный фрагмент кода, но я после отладки подходов, которые могут мне помочь. У меня есть обширный код времени выполнения во всем приложении, и большие задержки не отображаются ни в одной из данных. Например, время выполнения обработчика OnResize основной формы минимально.
4 ответа
Если вы хотите узнать, что на самом деле занимает ваше время, попробуйте профилировщик. Sampling Profiler может ответить на ваш вопрос довольно легко, особенно если вы можете найти начало и конец раздела кода, который вызывает проблемы, и вставить OutputDebugString заявления вокруг него, чтобы сузить профилирование.
ХОРОШО. Задача решена. Я заметил, что проблема возникала только тогда, когда у меня были включены ключи командной строки для записи некоторой отладочной информации. Информация об отладке включала некоторые ответы HTTP, которые были записаны в журнал отладки (TMemo) на одной из вкладок. Когда HTTP-ответ включал большой блок без CR/LF, TMemo обернул его. Всякий раз, когда я изменял размер основной формы, размер TMemo изменялся, и элемент управления должен был снова визуализировать текст с переносом нового слова.
Показывать:
- начать новый проект Delphi
- поместите TMemo на форму
- согласовать его с клиентом
- скомпилировать и запустить
- вставьте большое количество текста в TMemo
- изменить размер основной формы
Я не буду награждать себя ответом, поскольку я действительно не предоставил достаточно информации, чтобы кто-нибудь еще мог ее решить.
КСТАТИ @ Мейсон - SamplingProfiler подхватил бы этот - учитывая, что выполнение находится внутри VCL, а не в моем коде?
Запустите ваше приложение в профилировщике производительности AQTime (входит в XE, но вы можете получить ограниченную по времени версию на их веб-сайте).
Сделайте некоторое фанатическое изменение размера некоторое время, а затем остановите приложение.
После этого вы увидите, какая именно функция была вызвана много раз и где было потрачено больше всего времени.
Подход грубой силы, который может дать результаты.... Поместите сообщение отладки в OutputDebugString() из каждого события изменения размера, отправив имя элемента управления в виде строки, которая будет отображаться. Это может показать вам, какие из них называются "много".
Может возникнуть ситуация, когда элементы управления сталкиваются друг с другом, отключая каскадные события изменения размера. Как трое братьев и сестер на заднем сиденье компактного автомобиля, когда они начинают бороться за свое положение, им может понадобиться некоторое время, чтобы "успокоиться".
Не заставляй меня поворачивать эту машину вокруг...
Журнал отладки (доступный для просмотра в IDE или с помощью внешнего средства просмотра ODS) может показать, какие из них вызывают наибольшее количество проблем, если они появляются несколько раз для одного "инициированного пользователем события изменения размера".