Что вы делаете, чтобы увеличить скорость запуска (или уменьшить время запуска) вашего приложения Delphi?
Помимо специфики приложения, существует ли стандартный трюк, который всегда работает?
Примечание. Я не говорю о быстрых алгоритмах или подобных. Только увеличение производительности при запуске с точки зрения скорости.
Попробуйте сделать как можно меньше в основной форме OnCreate event. Скорее переместите некоторую инициализацию на другой метод и сделайте это, как только форма будет показана пользователю. Индикатор, что приложение занято занятым курсором мыши, проходит долгий путь.
Проведенные эксперименты показывают, что если вы принимаете то же самое приложение и просто добавляете к нему уведомление о запуске, пользователи действительно воспринимают это приложение как ускоряющееся!
Кроме того, вы можете делать обычные вещи, такие как исключить отладочную информацию и включать оптимизацию в компилятор.
Кроме того, не создавать все свои формы автоматически. Создайте их динамически по мере необходимости.
В параметрах проекта не создавайте автоматическое создание всех ваших форм спереди. Создавайте и освобождайте их по мере необходимости.
Ну, как предложил Аргалатыр, я поменяю свой комментарий на отдельный ответ:
В качестве расширения ответа "не авто создавать формы" (который будет достаточно эффективным сам по себе) я предлагаю отложить открытие подключений к базам данных, интернету, серверам COM и любому периферийному устройству, пока вам это не понадобится.
Перед вашей формой отображается три вещи:
Как указывали другие, вы должны автоматически создавать только небольшое количество форм (особенно если они сложные формы с большим количеством компонентов) и не должны обрабатывать длинные обработки в событиях OnCreate этих форм. Если, случайно, ваша основная форма очень сложна, вы должны ее перепроектировать. Одна из возможностей состоит в том, чтобы разделить основную форму на несколько кадров, которые загружаются по требованию.
Также возможно, что один из блоков инициализации занимает некоторое время для выполнения. Чтобы проверить, поместите точку останова в первую строку вашей программы (основной блок "begin..end" в файле .dpr) и запустите программу. Весь блок инициализации будет выполнен, а затем точка останова остановит выполнение.
Аналогичным образом вы можете выполнить шаг (F8) по основной программе - вы увидите, сколько времени потребуется для каждой созданной автоматически формы.
Отобразите заставку, чтобы люди не заметили длительное время запуска:).
Развертывание приложения может (и обычно это происходит!) происходить так, как разработчик, возможно, не рассмотрел. По моему опыту это создает больше проблем с производительностью, чем хотелось бы.
Общим узким местом является доступ к файлам - файл конфигурации, ini файл, который требуется для запуска приложения, может хорошо работать на машине-разработчике, но выполняться с ужасом в разных ситуациях развертывания. Точно так же ведение журнала приложений может препятствовать производительности - как по причинам доступа к файлам, так и по журнальным файлам.
То, что я вижу так часто, - это приложения с богатым клиентом, развернутые в среде Citrix или на общем сетевом диске, где команда инфраструктуры решает, что временные файлы пользователя или личные файлы хранятся в месте, где приложение обнаруживает проблемы, и это приводит к проблемам с производительностью или стабильностью.
Еще одна проблема, которую я часто вижу, влияет на производительность приложения - это метод, используемый для импорта и экспорта данных в файлы. Обычно в бизнес-приложениях Delphi я вижу функции экспорта, которые работают с DataSets - итерация и запись в файл. Рассмотрим метод, используемый для записи в файл, рассмотрите доступную память, считайте, что "папка", записываемая в/чтение, может быть локальной для машины или может быть на удаленном сервере.
Разработчик может утверждать, что это проблемы с установкой, вне сферы их интереса. Обычно я вижу много циклов анализа разработчика по этой проблеме, прежде чем он будет идентифицирован как "проблема инфраструктуры".
Поставьте длинные задачи (открывайте подключения к базе данных, подключайтесь к серверу приложений и т.д.), которые должны выполняться при запуске в потоке. Любая функциональность, зависящая от этих задач, отключается до тех пор, пока поток не будет выполнен.
Это немного обманщик. Основная форма появляется сразу, но вы получаете только более быстрое время запуска.
Сжатие исполняемого файла и любых DLL с помощью ASPack или UPX. Время декомпрессии более чем компенсируется более быстрым временем загрузки.
UPX использовался как пример о том, как быстрее загружать FireFox.
Обратите внимание, что есть downsides для сжатия exe.
Это только для IDE, но Chris Hesick сделал запись в блоге о увеличении производительности запуска в отладчике.
Самый быстрый код - это код, который никогда не запускается. Совершенно очевидно, действительно;)