Сделал простейшую программу(Одна форма и пару кнопок) а она весит всего лишь 11.2MB
Но мне кажется это черезчур много...
Почему программы такие жирные?
Модератор: Модераторы
-
Павел Ишенин
- постоялец
- Сообщения: 475
- Зарегистрирован: 24.03.2007 09:16:52
-
*vmr
- постоялец
- Сообщения: 168
- Зарегистрирован: 08.01.2007 00:46:07
- Откуда: Киев
- Контактная информация:
Павел Ишенин писал(а):На текущий момент просто на это все забили. Как будет нечем заняться - будем решать smartlink проблемы.
Смартлинк уже есть. Только он не может эффективно выполнять свою работу -- LCL абсолютно не смартлинкабельный
Про все эти проблемы можно узнать прочитав описание "идеологии" библиотеки KOL (там приводятся недостатки VCL, в LCL же ситуация намного хуже)
*vmr писал(а):Смартлинк уже есть. Только он не может эффективно выполнять свою работу -- LCL абсолютно не смартлинкабельный
Про все эти проблемы можно узнать прочитав описание "идеологии" библиотеки KOL (там приводятся недостатки VCL, в LCL же ситуация намного хуже)
Ну, VCL по сравнению с LCL просто тощая
ИМХО, ситуацию исправить можно только кардинально - выбором в качестве основы одного GUI API, например, GTK2(опять же, ИМХО, разумеется) и выбросом на свалку всего остального, например, Qt(что-то мне подсказывает, что эта прослойка самая жирная:) ) Особенно актуальным это становится в свете:
http://trolltech.com/28012008/28012008
P.S. А KOL, фактически, непереносим.
Здравствуйте!
Пожалуй, немного оживлю тему.
Делаю простейшую программу - гуи для конфигурирования (одна форма с кнопками, полями и тд...). Под линукс (gtk2).
В настоящее время после strip бинарник весит 2,6Мб. Хотелось бы еще уменьшить размер, насколько это возможно, но без использования upx.
Поэтому несколько вопросов:
Пожалуй, немного оживлю тему.
Делаю простейшую программу - гуи для конфигурирования (одна форма с кнопками, полями и тд...). Под линукс (gtk2).
В настоящее время после strip бинарник весит 2,6Мб. Хотелось бы еще уменьшить размер, насколько это возможно, но без использования upx.
Поэтому несколько вопросов:
- 1) Даст ли что-нибудь обновление лазаруса из свн? Пока делаю в 0.9.26 (Где то в интернете попадалась информация, что идет работа по оптимизации линковщика, уменьшению размера выходного файла).
2) Даст ли выигрыш в размере динамическое создание компонентов формы во время запуска программы вместо набрасывания их на форму в редакторе? Может быть какие-то другие приемы программирования помогут?
3) Может быть в параметрах компиляции указать какие-нибудь хитрые ключи оптимизации?
4) Something else...? Вобще, стоит ли эта игра свеч?
-
betatester
- постоялец
- Сообщения: 276
- Зарегистрирован: 27.04.2007 22:21:45
- Контактная информация:
Рекомендации по сокращению размера.
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%.
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 информация кладёться рядом с исполняуемым файлом
НО:
под Вынь должно работать
под Никсы, не знаю.
под Мак, в принципе, работать не будет.
----------------
имхо, нет. Скорость интернета сейчас достаточно высока во всём мире, и с распространнием файлов проблем возникнуть не дожно.
Опять же про свечи... Кто-нить может написать ГУИ программу (без использвания встроенных в бинарик изображений и других ресурсова, а так же почистив её strip-ом) больше 10 мегабайт?
на LCL всё-таки не вирусы пишут. Гнаться за мелкоразмером смысла нет.
2 sash0k. Заглядывай иногда на forum.e-kirov.ru
---------------
Очень плохой совет! Не делайте так в своём коде никогда!
1-х. тип String это одна из наиболее удобных вещей в Паскале. Отказываться от них - себе во вред.
2-х. использование указателей, рисково. Особенно начинающим Указатели нужно использовать исключительно в крайних случаев.
3-х если уж заменять array of String , тогда нужно избавиться и от самого массива, например, на PPChar (указатель на массив PChar)
----------------
получить маленькие размеры вполне реально. а обёрточный код, нужен для достижения кроссплатформенности и удобства (обёрточки весят мало...)
Вообще, писать на "чистом API" это получить трудночитабельный и в целом, не структурированный код. Даже если писать на только под одну GUI систему (только WinAPI, или только gtk), то так или иначе, программист будет облегчать себе жизнь, создавая всякого рода удобные обёртки. И использование этих обёрток не сильно увеличит итоговый размер файла, зато упростит жизнь.
Ну, и как написал ранее Павел - патчи приветствуются
----------------
Используя опцию 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), то так или иначе, программист будет облегчать себе жизнь, создавая всякого рода удобные обёртки. И использование этих обёрток не сильно увеличит итоговый размер файла, зато упростит жизнь.