Keeper89, критична скорость загрузки плагина, считаю что грузить 2,5 МБ будет дольше чем 0, 5 МБ. Да, поскольку это DLL вероятно повторный вызов будет уже без посторной загрузки (вероятно т.к. не сильно искушен в архитектуре TC). Но такой рост размера меня лично сильно шокирует  Аж охота пользоваться XE2 пропала.
Упаковать -- выиграем в размере, проиграем в скорости распаковки. Смысл? 

  Не факт. Винда обычно грузит только то что ей нужно. Обычно делфовый экзешник набивается под завязку всяким лутом типа RTTI или ресурсов. Если сходу не грузить все формы в память, то загрузка будет столь же быстрой как и раньше.

dll может быть и 300 метров - в память он грузиться целиком не станет.
Вот если он упакован пакером, тогда станет.
Так что не думаю, что размер критичен. Если его заархивировать, то получится всего полметра.
Для инета не критично. Для винта вообще не заметно.
Я бы не заморачивался бы на эту тему.

Вот кстати одна из причин роста монстраобразности исполняемых модулей

Alexeis, ухты...

А чему удивляемся? 

northener, да я просто сам таким не пользуюсь... примеры видел, но видать забыл уже, что такое возможно.
А практическое применение такому где может быть?

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

Это сообщение отредактировал(а) bems - 6.6.2012, 08:46

  Ну одно из применений может быть в купе с компилятором делфей. Самомодифицирующаяся программа. Внутри программы создал код bpl, загрзузил и заюзал, то что только что написал. 
  Можно также представить себе сиситему плагинов, где в xml файле будет описано содержимое плагина (классы и функции), а также несколько вариантов конфигураций, в виде возможных значений параметров (кстати о плагинах). В любом случае это неплохая альтернатива COM. 
  Еще неплохой пример. Браузер грузит html страничку, находит тег embed / object и используя метаинформацию из него определяет кто должен рендерить содержимое и какие данные нужно передать объекту для правильной работы. 
  Вспоминаем типичную схему разработки классов на COM. Написали класс, к нему максимально полный интерфейс. Через пару месяцев возникла необходимость расширить его. Что делаем? Пишем новый дополняющий старый. Потом 3й, 4й 5й и получаем форменное безобразие. С другой стороны далеко не всегда позднее связывание требует максимального быстродействия. Можно сочетать интерфейсы с рефлексией. Например, там где требуется максимальное быстродействие используем COM интерфейсы, которые получаем из объектов, которые были созданы и связаны с основной программой по их строковому описанию.