0.2.1. Экономия расходов памяти

(Данный параграф добавлен 10.2010 вместе с публикацией KOL/MCK версии 3.00).

Он скукожился! (пародия на Дэвида Блэйна)

Первоначально KOL был нацелен только на экономию программного кода, но не ресурсов системы, таких как память. Начиная с версии 3.00 код был переделан таким образом, что размер экземпляров объектов TControl сократился примерно в 6 раз. Прежде всего, за счет того, что поля, использующиеся различными разновидностями контролов, не пересекаются, и их удалось совместить с помощью структуры с переменным наполнением (record CASE). Кроме того, более 600 байт, занятых указателями методов для обработки сообщений, стали создаваться динамически только для тех контролов, для которых назначены обработчики сообщений (а это часто далеко не все контролы, например, многие панели и метки, да и поля ввода вполне обходятся без обработчиков сообщений). Так же, как динамическая стала создаваться и использоваться структура TCommandActions (порядка 80 байт) – теперь в приложении выделяется один такой объект на отдельную разновидность контрола, вместо того, чтобы хранить эту запись внутри полей каждого экземпляра TControl. Плюс к этому, около 40 байт флажков, ранее занимавших по одному байту на каждый флажок типа Boolean, были сведены в несколько байтов, с расходованием на флажок одного бита.

В результате, расходы памяти на экземпляр TControl сократились с более чем 1,5 Кбайта до 300-350 байт без учета необязательного блока событий (в зависимости от набора используемых опций компиляции). Предполагается, что такой подход, в случае адаптации нововведений в версии, предназначенной для Windows CE (ветка KOL-CE), поможет создавать менее требовательные к оперативной памяти приложения. Но и для основной ветви проекта KOL экономия памяти так же может быть полезна.

0.3. Визуальная разработка gui-приложений в kol: Mirror Classes Kit

Если гора не идет к Магомету, то Магомет придет к горе. (Арабская пословица)

Нельзя не остановиться на очень важной теме, обозначенной в заголовке этой главы. Программисты Delphi, сидя в IDE, давно привыкли к тому, что проект с использованием библиотеки VCL (а теперь и CLX - "кайликс") очень удобно разрабатывать визуально, т.е. методом набрасывания на форму компонентов и визуальной настройкой их свойств в Инспекторе объектов.

Разумеется, в первых версиях KOL был не визуальным (библиотека и задумывалась как не визуальная). Но в некоторый момент настал час X, и под влиянием многочисленных требований от пользователей KOL, я вынужден был разработать набор визуальных ("зеркальных") классов - Mirror Classes Kit - он так и называется. Что это такое. Это набор классов времени разработки (Design Time), которые используются только для того, чтобы определить, какие объекты KOL используются в модуле во время разработки (Run-time).

Сами эти зеркальные классы во время исполнения никак в программе не задействованы, и даже не существуют, но на этапе разработки они занимаются генерацией кода для инициализации форм, инициализации и запуска приложения. И все. Т.е. MCK работает по принципу адд-она или плагина к Delphi IDE, модифицируя файлы проекта так, что при их переработке в машинный код компилятор Delphi "не видит" зеркальных классов, ссылок на ресурсы .dfm формы, а компилирует только код, сформированный MCK-зеркалами в процессе настройки их программистом.

Фактически, разработка приложений в MCK - в отличие от "чистого KOL" (этот термин возник, видимо, по аналогии VCL - против "чистого API") ни в коем случае не увеличивает размер приложения, всего лишь упрощая труд разработчика (так что аналогия - весьма отдаленная).

В дополнение к уже сказанному, отмечу, что проекты MCK, в отличие от рукописных проектов KOL, автоматически поддерживают технологии Collapse и FormCompact. Техника Collapse заключается в том, при включении в опции проекта символа условной компиляции Pcode, зеркальные классы автоматически генерируют П-код для Collapse-машины, и таким образом удается несколько уменьшить код сколько-нибудь крупных KOL-приложений, использующих MCK. Техника FormCompact еще проще: достаточно включить свойство FormCompact в Инспекторе объектов, и сгенерированный псевдо-код для создания формы начинает обрабатываться интерпретатором этого псевдо-кода, автоматически. Сокращение кода, однако, будет заметно (в обоих случаях) только для случая достаточно большого числа контролов на форме, или большого числа форм в проекте (так как в проект дополнительно включается несколько десятков мелких вспомогательных процедур, общим размером около 1 К байта).