Компиляция проектов
В проге используется функция из модуля Math, например ArcCos() (или любая другая). В откомпилированный проект включается только требуемая функция или весь модуль Math?
Если включается только требуемая функция, то какого шайтана прогри так дохрена весят?
Вопрос поясню на примере:
В проге используется функция из модуля Math, например ArcCos() (или любая другая). В откомпилированный проект включается только требуемая функция или весь модуль Math?
Если включается только требуемая функция, то какого шайтана прогри так дохрена весят?
Потому что это Виндовс. Кроме того по настоящему кушает память только работа VCL и БД, если ты конечно не напихаеш туда кучу всего.
Ты потробуй в диспечере задачь размер в памяти твоей проги посмотреть, при этом поделай с ней что нибуть (сверни, разверни и т.п.), много интересного уфидиш. Но в проект обязательно включаются области inicialisate и finalisate (сзаранее извеняюсь за ошибки в написании, не помню как точно пишется) и ресурсы модюля, даже если ты его просто указал, но ни чего из него не использовал.
Вопрос поясню на примере:
В проге используется функция из модуля Math, например ArcCos() (или любая другая). В откомпилированный проект включается только требуемая функция или весь модуль Math?
Если включается только требуемая функция, то какого шайтана прогри так дохрена весят?
В этом и есть недостаток Delphi, комполируются все модули, находящиеся в uses.
Для умненьшения размера откомпилированной программы используй:
- утилиты для сжимания ехе-файла
- WinAPI ("основной" вес ехе придают визуальные компоненты, поэтому их лучше не использовать)
- KOL & MCK
ЗЫ Britney и misha_turist общайтесь на настоящем русском языке
В этом и есть недостаток Delphi, комполируются все модули, находящиеся в uses.
А что такое KOL & MCK?
А что такое KOL & MCK?
Если включается только требуемая функция, то какого шайтана прогри так дохрена весят?
Включается только требуемая функция. Поставь Project - Options - Linker - Map file в Publics - увидишь, что конкретно включается в результирующий EXE.
Код получается большим, потому что разделы initialization многих модулей VCL содержат код инициализации, использующий классы из этих модулей. Поэтому бывает достаточно указать его имя в uses, чтобы код программы увеличился. На форумах KOL даже пишется, на сколько конкретно увеличивает программу включение SysUtils, Classes или Forms, например.
Включается только требуемая функция. Поставь Project - Options - Linker - Map file в Publics - увидишь, что конкретно включается в результирующий EXE.
Код получается большим, потому что разделы initialization многих модулей VCL содержат код инициализации, использующий классы из этих модулей. Поэтому бывает достаточно указать его имя в uses, чтобы код программы увеличился. На форумах KOL даже пишется, на сколько конкретно увеличивает программу включение SysUtils, Classes или Forms, например.
А как с этим бороться?
А еще, выше было сказано, что лучше использовать ==inicialisate и finalisate==. Я человек в этих премудростях не секущий, поэтому объясните мне как это использовать и к чему это приведет.
А еще где-то слышал, что как-то можно выгружать из памяти (или не загружать, если они еще не требовались)не работающие компоненты, т.е. вызывать их только в нужные моменты.
!!!!Если кто-то может что-т внятно сказать по этой теме, то не томите!!!!
А как с этим бороться?
А еще, выше было сказано, что лучше использовать ==inicialisate и finalisate==. Я человек в этих премудростях не секущий, поэтому объясните мне как это использовать и к чему это приведет.
А еще где-то слышал, что как-то можно выгружать из памяти (или не загружать, если они еще не требовались)не работающие компоненты, т.е. вызывать их только в нужные моменты.
!!!!Если кто-то может что-т внятно сказать по этой теме, то не томите!!!!
Во первых inicialisate и finalisate - это разделы модуля : inicialisate выполняется при старте программы, finalisate - перед закрытием. Причём обращаю твоё внимание на то, что они выполняются при старте и перед закрытием именно программы, а не Apllication (прошу прощения за ошибки), т.е
program .......;
begin
//Выполняется inicialisate
//Текст твоей программы
//Выполняется finalisate
end.
Во вторых я не говорил, что их надо использовать, я говорил, что они обязательно выполнятся т.е если у тебя есть модуль Unit1 и ты в нём будеш в разделе inicialisate грузить в память 2 гига каких либо данных, то размер в памяти твоей программы будет 2 гига + твой код и не важно используеш ты эти данные или нет.
А что бы уметь динамически загружать(правильней будет сказать "создавать") объекты тебе для начала нужно работу с указателями освоить т.к. ВСЕ Delphi, а темболее VCL построено на указателях, просто компилятор умеет работу с ними представить как работу с обычными переменными.
А как с этим бороться?
Два варианта:
- не писать на VCL
- переписать VCL
Вот и делай. Удали все переменные форм, добавленные IDE, удали автоматически создаваемые формы, делай все самостоятельно. Об остальном позаботится Windows.
Два варианта:
- не писать на VCL
- переписать VCL
Вот и делай. Удали все переменные форм, добавленные IDE, удали автоматически создаваемые формы, делай все самостоятельно. Об остальном позаботится Windows.
Но для этого он должен понимать что такое указатель и с чем его едят, и понимать принципы создания и удаления объектов, иначе лесть в эти дебри "смерти подобно".
иначе лесть в эти дебри "смерти подобно".
В этом и состоит армейский метод воспитания. Так рождаются русские программеры.
А что бы уметь динамически загружать(правильней будет сказать "создавать") объекты тебе для начала нужно работу с указателями освоить т.к. ВСЕ Delphi, а темболее VCL построено на указателях, просто компилятор умеет работу с ними представить как работу с обычными переменными.
Ссылочку не подбросишь где все ясно и понятно?
(это случайно не так выглядит:
var a:^String
ну или что-нить такое с ^)
Но для этого он должен понимать что такое указатель и с чем его едят, и понимать принципы создания и удаления объектов, иначе лесть в эти дебри "смерти подобно".
Т.е. ты предлагаешь сделать свою библиотеку компонентов, я правильно понял?
Я тут начал работать программистом у себя в универе(институт у нас железнодорожный, поэтому мои познания в области программирования не так велики, как надобно, так что строго не судите(программирование у нас шло 1 семестр на Pascal'e)), и мне надо будет делать компьютерные лабораторные стенды, т.е. заменять осциллографы, генераторы и прочие пакости на мат. модели, а потом графически их представлять в окне. Поэтому мне потребуются куча разных компонентов (кнопки, едиты, таблицы, графики, имэджи и куча-куча других). Все мне не переписать по двум причинам:
1. Я понятия не имею как создаются компаненты, но это поправимо
2. За счет чего я смогу съэкономить место (неужели дельфи не может грамотно создать графические компоненты, а точнее в чем его беда???)
Не оставляйте меня без ответа!!!!!
Ссылочку не подбросишь где все ясно и понятно?
(это случайно не так выглядит:
var a:^String
ну или что-нить такое с ^)
Случайно так... )))))
http://www.codenet.ru/progr/delphi/learn/qualifying_types.php вот тебе ссылка, что нашёл, не обжайся, что мало. А так в сети поищи, там много долно быть.
Т.е. ты предлагаешь сделать свою библиотеку компонентов, я правильно понял?
Не оставляйте меня без ответа!!!!!
Я не предлагаю создание своей библиотеки...
Тебе не потребуется создание своих компонент: компонент - это та штука которая находится на "палитре компонентов", если ты её помещаеш на форму, то ты её исползуеш, а не как не создаёш. Кроме того они уже все есть.
А памяти у тебя хватит, у тебя програмки будут малениькие. А мы говорили про то что памяти просто программа написанная на Delphi кушает много, к примеру: минимальный размер в памяти стартовой программы (одно пустое окно) - 1,2МБайта +/-0.2 МБайта, а к примеру Word 2003 - 23МБайта, но ты сравни возможности Word и возможности стартового проекта Delphi(пустого окна).
А беда графики(окон, кнопок, меню и т.п.) в Delphi в том, что они грузят в память всё и сразу, а не помере необходимости....
Кстати если ты писать с Паскаля начнош, то ты гораздо большему научишся, чем если сразу с Delphi. А в Pascal-е есть библиотека TurboVision - это практически то-же самое что и визуальные эллементы в Delphi, но там всё ручками пишется, а это хоть, и дольше, и тяжелее, но знаний даёт гораздо больше.
А беда графики(окон, кнопок, меню и т.п.) в Delphi в том, что они грузят в память всё и сразу, а не помере необходимости....
Т.е. мне-то как быть?Повсюду использовать динамические переменные и массивы?
А как быть с графикой? Нельзя ли как-нибудь сделать так что бы сразу все не подгружалось, а потом исчезало, пока не нужно?
Допустим я замучу свою кнопку, чем же можно добиться, чтобы она была лучше стандартной, в каком месте я смогу уменьшить загрузку памяти?
Т.е. мне-то как быть?Повсюду использовать динамические переменные и массивы?
А как быть с графикой? Нельзя ли как-нибудь сделать так что бы сразу все не подгружалось, а потом исчезало, пока не нужно?
Допустим я замучу свою кнопку, чем же можно добиться, чтобы она была лучше стандартной, в каком месте я смогу уменьшить загрузку памяти?
Съекономить удасца, только с помощью объектов, создание которых пишеш ты сам(форм, модулей данных и т.д.).
Распределением памяти под визуальную часть, занимаются сами эти эллементы, если ты собираешся экономить место за их счёт, то тебе компоненты переписывать надо, а этим не стоит заниматься - это дело сложное, долгое, крапотливое и НЕ БЛАГОДАРНОЕ.
А динамисеские массивы и строки использовать лучше потому что удобней, если ты сзаранее не знаеш длину твоего массива или строки соответственно.
А указатели тебе имеет смысл использовать, если у тебя большие объёмы редко используемой информации, или при некоторых других специфических случаях, которые сейчас обеснять смысла не имеет.
Но всё что я сказал, косается только оперативной памяти, размер на диске это не уменьшит.
А так, если тебя это интересует, то пиши мне в личные, постараюсь объяснить.:)
Съекономить удасца, только с помощью объектов, создание которых пишеш ты сам(форм, модулей данных и т.д.).
Постой, а что же такое форма? Разве это не тот графический объект, который мы несчадно и в неограниченном количестве забрасываем всякими кнопочками,лабела и др. украшательствами?
С модулями понятно, а с формами не очень!
Постой, а что же такое форма? Разве это не тот графический объект, который мы несчадно и в неограниченном количестве забрасываем всякими кнопочками,лабела и др. украшательствами?
С модулями понятно, а с формами не очень!
Это именно он.
Ссылочку не подбросишь где все ясно и понятно?
(это случайно не так выглядит:
var a:^String
ну или что-нить такое с ^)
Во-первых, практически любую программу пожно написать без явного использования указателей. Во-вторых, как показала практика, на начальных этапах обучения программированию указатели только мешают понять смысл программы.
Так что пока плюнь на всякие вещи типа динамической памяти и initialization/finalization а также внутренними механизмами VCL. Главное - это понять сами принципы создания программ в Делфи, а всё остальное приложится вместе с опытом, ну и доп. знаниями. Для начала стоит разобраться с простыми событиями компонентов а также хоть немного осмыслить ООП.
А как быть с графикой? Нельзя ли как-нибудь сделать так что бы сразу все не подгружалось, а потом исчезало, пока не нужно?
Что-то мы не ту задачу решаем.
Это именно он.
В том-то и вопрос, как самому нарисовать форму? С этим я смогу разобраться. Вопрос в том, за счет чего я смогу уменьшить размер?!
Что-то мы не ту задачу решаем.
А почему не ту? Вопрос стоял в уменьшении размера самого файла и его процесса
А почему не ту? Вопрос стоял в уменьшении размера самого файла и его процесса
Это две взаимоисключающие, в большинстве случаев, задачи.
Вообще сейчас большой экзешник - норма (тоже самое можно сказать и про тот же Word, если учесть объем dll'ок). Да вобщем за примером ходить далеко не надо - у кого стоит Flash 8, посмотрите: размер Flash.exe - 16 (!) c хвостиком метров (ну или MX 2004 - 12Мб).
Кроме того, никто не обращал внимания сколько "левых" ресурсов цепляется в exe без вашего ведома (ResourceHacker'ом можно глянуть ради интереса)? Они могут нигде не использоваться - например иконки TBitBtn все равно есть в ресурсах, даже если и ни на одной форме нет TBitBtn, ну и так далее...
Кроме того, сам объем кода для обертки WinAPI (чем по сути и является VCL) довольно велик - кто пользовался MFC, знают, что при сборке проекта без runtime dll'ок (mfc42.dll, к примеру), получим те же 2-3 Мб...
Так что особо заморачиваться на размерах, ИМХО не имеет смысла :)
А чем не устраивает большой экзешник? Во многом это сказывается из-за визуальной среды разработки Delphi - очень большой объем кода используется для поддержки design time, а выкинуть его из класса, естественно, нельзя (обращали внимание на исходники Forms, например - сколько там условий if csDesigning in ComponentState ... ?). Кстати KOL на этом и построена - там нет design time кода в результирующем бинарнике.
Вообще сейчас большой экзешник - норма (тоже самое можно сказать и про тот же Word, если учесть объем dll'ок). Да вобщем за примером ходить далеко не надо - у кого стоит Flash 8, посмотрите: размер Flash.exe - 16 (!) c хвостиком метров (ну или MX 2004 - 12Мб).
Кроме того, никто не обращал внимания сколько "левых" ресурсов цепляется в exe без вашего ведома (ResourceHacker'ом можно глянуть ради интереса)? Они могут нигде не использоваться - например иконки TBitBtn все равно есть в ресурсах, даже если и ни на одной форме нет TBitBtn, ну и так далее...
Кроме того, сам объем кода для обертки WinAPI (чем по сути и является VCL) довольно велик - кто пользовался MFC, знают, что при сборке проекта без runtime dll'ок (mfc42.dll, к примеру), получим те же 2-3 Мб...
Так что особо заморачиваться на размерах, ИМХО не имеет смысла :)
Если он конечно не предназначен, чтобы гулять по нету.
А на счет уменьшения веса, то это решается довольно таки легко, инфы много в нете по этому поводу, да и из вышесказаного можно сделать много выводов
А чем не устраивает большой экзешник? Во многом это сказывается из-за визуальной среды разработки Delphi - очень большой объем кода используется для поддержки design time, а выкинуть его из класса, естественно, нельзя (обращали внимание на исходники Forms, например - сколько там условий if csDesigning in ComponentState ... ?). Кстати KOL на этом и построена - там нет design time кода в результирующем бинарнике.
Затем, что если программа которая толко и умеет что открывать несколько форм и чего-то по мелочи выполнять в памяти занимает 3-7 МБайт - это не очень хорошо. Для сравнения Delphi7 оперативки кушает ~10 МБайт, при всех его возможностях....
Затем, что если программа которая толко и умеет что открывать несколько форм и чего-то по мелочи выполнять в памяти занимает 3-7 МБайт - это не очень хорошо. Для сравнения Delphi7 оперативки кушает ~10 МБайт, при всех его возможностях....
+10000
Полностью с тобой согласен. Просто обидно, когда память тратится впустую! Ладно, простые студенческие программульки, которые складывают два числа в форме или сортируют массив, могут позволить себе отожрать несколько метров оперативы!А серьезные коммерческие проекты? Представляете, сколько будет сжирать прога, которая, например, будет анализировать экономическую деятельность большого предприятия или которая будет заниматься моделированием какого-нибудь химического процесса. Целью данной темы является узнать о способах минимизации потребности в памяти(хоть оперативы, хоть постоянной). Допустим я только начинаю программировать на Delphi (хотя первые попытки были еще лет 5 назад, до этого я занимался спортивным программирование на Паскале). И мне в начале своего визуал-программерского пути будет весьма полезно узнать о том, что нужно делать для минимизации, дабы в будущем не пришлось переучиваться. Особенно меня все таки волнует оперативка, потому что с exe еще можно бороться архиватором, вот процесс...
Полностью с тобой согласен. Просто обидно, когда память тратится впустую!
Что-то вы гоните. Delphi IDE в процессе работы над проектом может занимать и 50, и 150 метров - зависит от сложности проекта и числа открытых контейнеров (форм/вкладок).
Обидно - пей водку и не программируй.
Для серьезных коммерческих проектов, как правило, повышенный расход памяти не является препятствием - у них другие приоритеты.
А вообще, домашнее задание - собери свой студенческий проект с пакетами. Размер файла сильно уменьшится, и в нем будет содержаться только твой код (за исключением секций импорта из пакетов). А теперь прикинь, сколько надо написать, файл (с пакетами!) был полтора-два метра размером...
Вы не учитываете простую вещь, что размер файла и расход памяти в процессе работы над проектом растет нелинейно. Первоначальная программа весит слишком много для такого простого кода, но потом ее размер увеличивается намного медленее (если не добавлять жирные библиотеки компонентов).
Чтобы убедиться окончательно, смотрим размеры DCU-файлов, созданных при компиляции модулей, непосредственно входящих в проект. Слабо 100 кб DCU написать? DFM-ы линкуются отдельно от DCU, в них только код самого модуля плюс некоторая дополнительная инфа для связывания, размером которой в нашем случае можно пренебречь (модуль Windows не в счет).
Непосредственно про расход памяти процессом - дружно читаем Рихтера или аналогичную литературу. Кто уже прочитал, должны понять, что архиваторы - добро, сжатие EXE - зло.
Остается еще добавить: ребята, почитайте как устроен и работает менеджер памяти дельфи.
ЗЫ: Так здесь обсуждается размер екзешника или размер программы в памяти? :)
ЗЫ: Так здесь обсуждается размер екзешника или размер программы в памяти? :)
А все вместе нельзя? Если так охота конкретности, то пусть будет размер процесса.