Размер EXE. Опять размер

← →
REA (2002-03-25 10:34) [0]

Замечено, что от версии к версии размеры exe в Delphi пухнут, что в целом не удивительно. В Delphi 6 зачем-то создается несколько секций в заголовке PE для прилинкованных статически BPL. Линковка при загрузке производится по именам функций типа @TCustomForm@WantChildKey$qqrp17, что занимает до 60% процентов от объема приложения. Спрашивается: нафига?
Это интерпретатор что-ли? {$M-} разумеется не помогает, потому как RTTI тут не при чем, хотя она тоже на размер ощутимо влияет.
Названия компонентов тоже в явном виде. Полностью отключить RTTI я не рискую. Неужели нельзя придумать Smart RTTI, который при компиляции определял бы - надо включать RTTI в класс или нет?
Упаковка ресурсов конечно помогает, но почему-бы не встроить это в компилятор? А OC сама паковать ресурсы не умеет?
Вобщем мой exe, который раньше занимал 70k, весит уже 450k (c RunTime packages) и дальше думаю будет расти даже без изменений кода.

← →
drpass © (2002-03-25 10:55) [1]

Ну и что? IMHO размер, который файл занимает на диске, никакой роли сейчас не играет, времена ХТ и 286 уже давно прошли. 200КВ или 500КВ - какая разница? Зато важна эффективность кода, скорость его выполнения. И тут Delphi6 даст фору всем предыдущим версиям Delphi, да и во многих случаях С++

← →
vuk © (2002-03-25 11:25) [2]

>Спрашивается: нафига?
Вам известен другой способ динамически загрузить DLL и получить адрес необходимой функции кроме как по имени? Да и RTTI здесь ни при чем.

>Полностью отключить RTTI я не рискую.
Да и не сможете.

← →
McSimm © (2002-03-25 11:31) [3]

Сомнение вызывает, что только из-за перехода на D6

> exe, который раньше занимал 70k, весит уже 450k

У меня много проектов переведено на D6. Максимальное увеличение - 30%

← →
Anatoly Podgoretsky © (2002-03-25 21:23) [4]

А вот это вообще вызывает огромное сомнение "дальше думаю будет расти даже без изменений кода.", дрожжи что ли

← →
Aleks1 (2002-03-26 02:41) [5]

2 Anatoly Podgoretsky © (25.03.02 21:23)
>А вот это вообще вызывает огромное сомнение "дальше думаю будет >расти даже без изменений кода.", дрожжи что ли

Сумлеваюсь я, однако, что Вы ответили "хорошо подумав". Имхо ЕХЕ-шник, рос, растет и будет расти с каждой новой версией компилятора.

← →
REA (2002-04-03 15:14) [6]

Ну например символы он сохраняет уже как Multibyte - а это уже в два раза больше, чем нужно нормальному некитайскому человеку.
А линковать с DLL можно было бы и по номеру. В крайнем случае создать Hash на функции. Мне не важно как функция называется в Exe и DLL OpenMyLibAndRun или OML, главное лишь бы уникально было. И работать кстати быстрее будет. Что же мне теперь короткие переменные писать всегда?

>А вот это вообще вызывает огромное сомнение "дальше думаю будет расти даже без изменений кода.", дрожжи что ли

Вот именно что дрожжи какие-то. Мне не нужен их COM и DCOM в 80% случаев - так вот нет - получи и распишись - неотъемлемая часть System. Сейчас еще .Net какой-нибудь туда гвоздиком прибьют и т.п. Картинки кстати тоже в кнопки хоть руками грузи - ImageList не помогает - хранит все в коде прямо. Тридцать кнопок BitBtn с одинаковой картинкой и exe уже ощутимо распух.

← →
drpass © (2002-04-03 15:20) [7]

За все надо платить. В данном случае ты платишь за быстроту создания приложения. Если тебе хочется чего-нибудь более компактного, ничто не запрещает использовать WinAPI, и в этом случае твое приложение будет крохотным и быстрым. Но руками придется поработать намного больше

← →
Anatoly Podgoretsky © (2002-04-03 15:27) [8]

Anatoly Podgoretsky © (25.03.02 21:23)
Хорошо подумал, у него будет расти не от изменения версии, а сам по себе, прочитай еще раз его постинг. Во вторых он явно о чем то умалчивает, переход с версии на версию не даст прироста в 70 до 450 кб, а вот MBO я верю

← →
VID © (2002-04-03 16:46) [9]

to drpass:
EXE должен быть максимально маленьким. Клмпилятор OP должен уметь делать это если таковое возможно...
А вдруг, например, программер захочет выложить свой прогу в инет...
Конечно есть люди, для которых скачать 500 или 70 КБ не представляет никакой разницы. Но есть и другие... у которых поременка, у которых коннект на 9600-14400... Им уже есть разница.

2VID: а вдруг да если... мне зачастую нужно сделать прогу за один месяц... и мне плевать на размер... винты щас большие...
А если человек хочет выложить прогу в инет, или еще хуже - продать, то пусть будет добр пишет ее так, как хочет продать...
Я понимаю стремление сделать исполняемый код небольшим, но тут зачастую руководствуются правилом - нужна скорость разработки - плати объемом... можно еще писать на асме...

← →
REA (2002-04-04 11:23) [11]

Вообще-то если продукт серьезный, за месяц его не сделать. В данном случае у меня более 100 plugin dll и порядка 15 exe. Так что в сумме очень немало - память-то не резиновая (а менеджер памяти микрософта и совсем сводит ее на нет через сутки активной работы). На асме сам понимаешь много не напишешься - только ключевые моменты.
А вообще-то форум перерастает в демагогию - типа придется смириться. Я же ожидал дельных советов, как уменьшить размер не прибегая к asm. Это все понятно за что платим и чем, но все должно быть разумно - хочу плачу, хочу нет.
Кстати в BitBnt пришлось сделать картинки отдельно (не в actions) и попытаться унаследовать все от одной формы (что окончательно не удалось, но размер все же сократило), но это в целом проблемы не решает. Конечно 70к - это exe упакованный паковщиком ресурсов - нормальный где-то 200-250 был (с картинками как ресурсы) на Delphi 4. Мне удавалось выкинуть много лишнего из системных файлов и сократить размер до 100к, но в чужой код лезть - это дело неблагодарное.

Есть еще библиотека KOL. Сам не пробывал, но авторы утверждают, что код сильно сокращается...
http://bonanzas.rinet.ru/rindex.htm

← →
vrRaven (2002-04-07 19:33) [13]

Я полностью согласен с drpass!
Времена каменного века прошли, и сейчас размер ни имеет особого значения!

Размер EXE. Опять размер Найти похожие ветки