Почему программы такие жирные?

[AMD]

Сделал простейшую программу(Одна форма и пару кнопок) а она весит всего лишь 11.2MB
Но мне кажется это черезчур много...

[alexs]

смотри FAQ - избитая тема
(подсказка strip+upx(по желанию))

[YouROK]

На сколько я знаю upx сжимает только ехе файл а в памяти после распоковки опять столькоже будет, думаю в будущем будет меньший размер, остаеться только ждать или переходить на win api

[alexs]

думаю в будущем будет меньший размер

это врядли - идеалогия LCL таков - что уменьшение врядли предвидется - будет только увеличиваться.

[serg_iv]

На сколько я знаю upx сжимает только ехе файл а в памяти после распоковки опять столькоже будет,

В Линуксе после запуска файла обработанного upx, он в памяти занимает почти в два раза больше места, чем обработанный или не обработанный strip'ом.

[Павел Ишенин]

это врядли - идеалогия LCL таков - что уменьшение врядли предвидется - будет только увеличиваться.

На текущий момент просто на это все забили. Как будет нечем заняться - будем решать smartlink проблемы. Идеология тут не причем. Если есть желание - патчи всегда принимаются.

[alexs]

Павел Ишенин
Я чуть про другое - в LCL много "обёрточного" кода, этим же грешит и VCL от дельфина. Поэтому не реально получить маленькие размеры, как при написание с использованием чистого API системы.

Но, на мой взгляд, это и не нужно. Быстродействие программы не страдает - а это важнее.

[*vmr]

На текущий момент просто на это все забили. Как будет нечем заняться - будем решать smartlink проблемы.

Смартлинк уже есть. Только он не может эффективно выполнять свою работу -- LCL абсолютно не смартлинкабельный

Про все эти проблемы можно узнать прочитав описание "идеологии" библиотеки KOL (там приводятся недостатки VCL, в LCL же ситуация намного хуже)

[vital]

Смартлинк уже есть. Только он не может эффективно выполнять свою работу -- LCL абсолютно не смартлинкабельный

Про все эти проблемы можно узнать прочитав описание "идеологии" библиотеки KOL (там приводятся недостатки VCL, в LCL же ситуация намного хуже)

Ну, VCL по сравнению с LCL просто тощая ИМХО, ситуацию исправить можно только кардинально - выбором в качестве основы одного GUI API, например, GTK2(опять же, ИМХО, разумеется) и выбросом на свалку всего остального, например, Qt(что-то мне подсказывает, что эта прослойка самая жирная:) ) Особенно актуальным это становится в свете:
http://trolltech.com/28012008/28012008

P.S. А KOL, фактически, непереносим.

[Attid]

А KOL, фактически, непереносим.

вот светлою будушее за KOL который надо на АПИ гтк2 написать =)

[vital]

А KOL, фактически, непереносим.

вот светлою будушее за KOL который надо на АПИ гтк2 написать =)

Ну, это будет уже не KOL Тогда уж напрямую с иксами работать надо - будет идеологически вернее

P.S. Что, разумеется, сузит ареал обитания либы

[Attid]

ну так мышкой формы создовать нельзя будет. хотя можно будет какой нибуть VISG: visual and smart GUI builder использовать . .

[Sash0k]

Здравствуйте!
Пожалуй, немного оживлю тему.
Делаю простейшую программу - гуи для конфигурирования (одна форма с кнопками, полями и тд...). Под линукс (gtk2).
В настоящее время после strip бинарник весит 2,6Мб. Хотелось бы еще уменьшить размер, насколько это возможно, но без использования upx.
Поэтому несколько вопросов:

1) Даст ли что-нибудь обновление лазаруса из свн? Пока делаю в 0.9.26 (Где то в интернете попадалась информация, что идет работа по оптимизации линковщика, уменьшению размера выходного файла).
2) Даст ли выигрыш в размере динамическое создание компонентов формы во время запуска программы вместо набрасывания их на форму в редакторе? Может быть какие-то другие приемы программирования помогут?
3) Может быть в параметрах компиляции указать какие-нибудь хитрые ключи оптимизации?
4) Something else...? Вобще, стоит ли эта игра свеч?

[betatester]

Рекомендации по сокращению размера.
0. Откомпилите все, что есть в исходных кодах библиотек FPC с параметром fpc_smart (т.е. выплоните make fpc_smart). Аналогично стоит поступить с LCL и с GTK2/QT (если вы его используйте). Ибо просто make fpc_smart будет собирать интерфейс по умолчанию (GTK1?).

1. Тщательно проверьте, что у вас в классах записано в секции Interface->Uses. Выкиньте все ненужное. Особенности SmartLink в том, что все, что есть в указанной выше секции он линкует автоматом. Вообще - почистите обе секции Uses от всего ненужного! Все нужное, но не используемое в секции Interface следует перенести в Implemantation->Uses. По умолчанию в секцию Interface->Uses добавляется Classes и SysUtils. Проверьте, нужны ли вам эти юниты именно в этой секции и нужны ли они вообще.

2. Если у вас вызывается одна или две функции из какого-то системного юнита - лучше скопировать описание функции и нужных ей типов к себе в Implementation->Type, чем подключать модуль целиком.

3. Не используйте, по возможности, картинки, встроенные в визуальные компоненты - они хранятся в бинарнике в текстовом виде. Более точно - в виде XPM. Лучше всего загружать такие картинки в процессе выполнения программы из файлов на диске. Эта же рекомендация распространяется и на картинки, положенные в ресурсы проекта программой lazres.

4. По возможности, не используйте String и Array [] of String. Все Array [] of String превратите в Array [] of PChar. Особенно это справедливо для секции Const.

5. Возможно, стоит рассмотреть и использовать альтернативный метод обработки Exception - т.е. вместо Raise Exception использовать простой вывод на консоль через WriteLN(); Exit; или WriteLN(); Halt;; Это - спорная рекомендация. Однако она может быть полезна в случае, если при отладке программы всплывающее окно Exception больше мешает, чем помогает.

Реальный выигрыш зависит от проекта и может достигать 30%.

[скалогрыз]

В идеале, чтобы программа была "как можно меньше" - нужно писать свои библиотеки. Естественно, придёться написать свой "редактор ГУИ" под эти библиотеки... и т.д. т.п.

Ну, и как написал ранее Павел - патчи приветствуются
----------------
Используя опцию SmartLinking можно поэксперементировать:
подключяя один модуль за другим, смотреть из-за какого модуля на сколько вырастает размер программы (и под какую ОСь)
----------------
Чтобы программы создавались не сильно жирными используйте ключик -Xg (для версий Лазаруса выше 0.9.26)
(Project -> Compiler Options -> Linking). в этом случае debug информация кладёться рядом с исполняуемым файлом
НО:
под Вынь должно работать
под Никсы, не знаю.
под Мак, в принципе, работать не будет.
----------------

4) Something else...? Вобще, стоит ли эта игра свеч?

имхо, нет. Скорость интернета сейчас достаточно высока во всём мире, и с распространнием файлов проблем возникнуть не дожно.
Опять же про свечи... Кто-нить может написать ГУИ программу (без использвания встроенных в бинарик изображений и других ресурсова, а так же почистив её strip-ом) больше 10 мегабайт?
на LCL всё-таки не вирусы пишут. Гнаться за мелкоразмером смысла нет.

2 sash0k. Заглядывай иногда на forum.e-kirov.ru
---------------

4. По возможности, не используйте String и Array [] of String. Все Array [] of String превратите в Array [] of PChar. Особенно это справедливо для секции Const.

Очень плохой совет! Не делайте так в своём коде никогда!
1-х. тип String это одна из наиболее удобных вещей в Паскале. Отказываться от них - себе во вред.
2-х. использование указателей, рисково. Особенно начинающим Указатели нужно использовать исключительно в крайних случаев.
3-х если уж заменять array of String , тогда нужно избавиться и от самого массива, например, на PPChar (указатель на массив PChar)
----------------

Я чуть про другое - в LCL много "обёрточного" кода, этим же грешит и VCL от дельфина. Поэтому не реально получить маленькие размеры, как при написание с использованием чистого API системы.

получить маленькие размеры вполне реально. а обёрточный код, нужен для достижения кроссплатформенности и удобства (обёрточки весят мало...)

Вообще, писать на "чистом API" это получить трудночитабельный и в целом, не структурированный код. Даже если писать на только под одну GUI систему (только WinAPI, или только gtk), то так или иначе, программист будет облегчать себе жизнь, создавая всякого рода удобные обёртки. И использование этих обёрток не сильно увеличит итоговый размер файла, зато упростит жизнь.