[Guaho]

Здравствуйте!
Продолжаю работу над большим (по моим меркам) приложением - базой данных. Проект масштабный, время запуска приложения - 25...30 секунд. В коде стартового запуска для каждой формы - создание формы (Application.CreateForm), активация датасетов, загрузка настроек, стартовая сортировка в таблицах и т.п.
Недавно добавил в код запуска фиксацию времени выполнения операций, и увидел, что формы средней сложности создаются порядка 0,5 с, а сложные - от 1 до 1,5 секунд. Да, там действительно много чего есть на этих формах, потому и так долго. Но в сумме на создание форм в моём приложении уходит в среднем не менее 10 с, что очень существенно.
И возник вопрос - не существует ли в природе механизма кэширования данных формы? Т.е. механизма, который действия в Application.CreateForm заменял бы сразу подстановкой ранее скомпилированного куска данных? Среда проектирования - Делфи 7. Пытался гуглить данный вопрос - ничего не нашёл.

[lmikle]

Хм, а зачем создавать все формы при старте приложения? Они что, все сразу нужны? Не лучше ли создавать формы по мере надобности и, кстати, уничтожать их по закрытию. Так и памяти будет меньше расходоваться...

[Guaho]

Если не создать всё сразу, будут тормоза при показе несозданных форм (в некоторых случаях до нескольких секунд). На мой взгляд, такое торможение категорически неприемлемо (меня это всегда сильно раздражает, когда такое встречаю в каких-либо программах). А обратиться пользователь может вообще к любому окну после начала работы, и никто не знает, к какому, - такова специфика приложения. А памяти моё приложение жрёт по нынешним меркам не много.
Кроме того, в этот раз я впервые использовал модель, когда компоненты TTable и TQuery не находятся все на одной форме, а разбросаны по целевым формам. А данные для Lookup-полей одних форм берутся из других, так что если не создать все окна, то нормального функционирования не будет (мелочёвка без датасетов, которая создаётся почти мгновенно, не в счёт). Не уверен, что такой подход хорош, но написание кода он упростил.
В принципе, вопрос столь долгого запуска приложения не страшно критичен, просто возникла мысль - а вдруг существует механизм кэширования, о котором я не знаю.

[lmikle]

Ну, стандартные настройки формы много времени не занимают.
Как я понимаю, основное время уходит на открытие датасетов, закачку данных и их сортировку. Особенно, если данных много.
В целях оптимизации можно посоветовать:
1. Ограничить объем скачиваемых данных. Например, по пользователю (если есть разделение кому что можно видеть) или по дате (по умолчанию ставим фильтр только за сегодня/текущую неделю, если надо пользователь изменит фильтр и обновит данные, но тут он, пользователь, намеренно укажет, что это надо сделать, так что подождет)
2. Полностью отказаться от TTable и делать все на TQuery и сортировку вставлять в запрос, а не сортировать самому на клиенте.
3. При использовании TQuery все данные из справочников подствлять опять же в запросе (пусть СУБД пашет), а справочники для редактирования хранить централизованно в одном экземпляре (например на главной форме или на DataModule).

[Guaho]

Благодарю за ответ!
В том-то и дело, что моём приложении, увы, создание форм занимает немалое время. Уж больно много наворочено компонентов на формах. Время создания - порядка 0,5 ... 1 ... 1,5 с для сложных форм, а в сумме набегает более 10 с. На фоне общего времени запуска (порядка 25...30 с) эти 10 с составляют немалую долю, от трети до почти половины.
Как ни странно, при этом инициализация датасетов на большинстве форм занимает меньше времени, чем создание форм - обычно 0,1...0,3 с, редко когда 0,5.
Ещё много времени (но только в сложных случаях, до 3,5 с) сжирает динамическое (по содержимому связанных таблиц) создание деревьев классификации. Деревья - с изображениями, и как их создавать иным способом, я не придумал (хотя есть кое-какие идеи, но это долгая возня с неопределённым результатом).
Остальные рекомендации мне вряд ли подойдут, т.к. либо не подходят под специфику приложения, либо требуют серьёзной перестройки, на что я пойти не могу (разработка длится почти 5 лет, уже нет сил на отклонения от курса).
Ограничить начальный объём данных по датам - нельзя, в этой базе даты не играют никакой роли, а важны сами записи, к любой из которой пользователь может обратиться в любой момент.
Сортировка у меня всегда в TQuery. TTable использую для поиска совпадений с имеющимися данными при добавлении записей (по некоторым причинам вариант с использованием исключений самого движка мне не подошёл).
Lookup-данные у меня прописаны в дизайн-тайме (добавляю в Query стандартные Lookup-поля). Как это делать на уровне SQL-запроса - не знаю.
И потом, в моём случае это не даст ускорения загрузки. Главные тормоза - при создании форм и некоторых деревьев классификации, и только в нескольких случаях - в блоках активации датасетов, но там выполняется ещё куча других действий, отдельно я не замерял.
Забыл сказать: база имеет файл-серверную архитектуру. Записей не особо много - в 1-й главной таблице - менее 2 тыс., во 2-й - менее 4-х тыс. Но - есть графические поля.