Уменьшение ресурсов!

← →
NaRuTo (2007-12-14 22:35) [0]

Я знаю что программы написанные на Delphi очень много забирают ресурсов компьютера, вот например моя простенькая программа в ОЗУ: занимает 32 MB, как другие программы более мощнее моей меньше раза в 2, а то и в 3. Хотя везде я прописываю Free либо Destroy;

Вопрос: Можно ли-уменьшить потребляемость моей программы ресурсов.

← →
homm © (2007-12-14 22:38) [1]

> [0] NaRuTo (14.12.07 22:35)
> Хотя везде я прописываю Free либо Destroy;

ужно прописывать не везде, а там, где нужно. Ты уверен, что память не течет?

← →
Johnmen © (2007-12-14 22:46) [2]

> Я знаю что программы написанные на Delphi очень много забирают
> ресурсов компьютера

Откуда?

> другие программы более мощнее моей

На сколько киловатт?

> Можно ли-уменьшить потребляемость моей программы ресурсов

Каких именно?

← →
Gydvin © (2007-12-14 22:51) [3]

код в студию

← →
Johnmen © (2007-12-14 22:53) [4]

> Gydvin © (14.12.07 22:51) [3]
> код в студию

Не надо здесь спама.

← →
Rouse_ © (2007-12-15 02:24) [5]

> вот например моя простенькая программа в ОЗУ: занимает 32 MB

Уж какой год человечество измеряет объем оперативной памяти гигобайтами - зачем ему твои 32?

← →
Германн © (2007-12-15 02:49) [6]

> Rouse_ © (15.12.07 02:24) [5]
>
>
> > вот например моя простенькая программа в ОЗУ: занимает
> 32 MB
>
> Уж какой год человечество измеряет объем оперативной памяти
> гигобайтами - зачем ему твои 32?
>

"Чем только не занимаются люди! Параллельно большому миру, в котором живут большие люди и большие вещи, существует маленький мир с маленькими людьми и маленькими вещами. В большом мире изобретен дизель-мотор, написаны "Мертвые души", построена Днепровская гидростанция и совершен перелет вокруг света. В маленьком мире изобретен кричащий пузырь "уйди-уйди", написана песенка "Кирпичики" и построены брюки фасона "полпред". В большом мире людьми двигает стремление облагодетельствовать человечество. Маленький мир далек от таких высоких материй. У его обитателей стремление одно -- как-нибудь прожить, не испытывая чувства голода.

Маленькие люди торопятся за большими. Они понимают, что должны быть созвучны эпохе и только тогда их товарец может найти сбыт. В советское время, когда в большом мире созданы идеологические твердыни, в маленьком мире замечается оживление. Под все мелкие изобретения муравьиного мира подводится гранитная база "коммунистической" идеологии. На пузыре "уйди-уйди" изображается Чемберлен, очень похожий на того, каким его рисуют в "Известиях". В популярной песенке умный слесарь, чтобы добиться любви комсомолки, в три рефрена выполняет и даже перевыполняет промфинплан. И пока в большом мире идет яростная дискуссия об оформлении нового быта, в маленьком мире уже вce готово: есть галстук "Мечта ударника", толстовка-гладковка, гипсовая статуэтка "Купающаяся колхозница" и дамские пробковые подмышники "Любовь пчел трудовых".
(с) ИИ ЕП

← →
Loginov Dmitry © (2007-12-15 10:01) [7]

> Я знаю что программы написанные на Delphi очень много забирают
> ресурсов компьютера

Не правда. По сравнению с современными средствами программирования программы, написанные на Delphi ведут себя очень даже скромно.

> вот например моя простенькая программа в ОЗУ: занимает 32
> MB

Если программа действительно простенькая, то, вероятно она выполняешь лишь одно действие -
GetMem(P, 32000000). А то и в цикле. А вот если программировать на Delphi уметь, то для того, чтобы программа стала отжирать 32МВ, нужно лет пять усиленно стараться (в зависимости от задачи).

> Хотя везде я прописываю Free либо Destroy

Тебе нужно прописывать везде Halt либо TerminateProcess(DWORD(-1), 0); Тогда притензий к твоим "поделкам" точно никаких не будет.

> Вопрос: Можно ли-уменьшить потребляемость моей программы
> ресурсов.

см. предыдущий пункт.

← →
@!!ex © (2007-12-15 11:52) [8]

> А вот если программировать на Delphi уметь, то для того,
> чтобы программа стала отжирать 32МВ, нужно лет пять усиленно
> стараться (в зависимости от задачи).

У меня прога написанная за неделю жрет около 30 метров памяти, и я зуб даю, что какой бы не был профи, не сможет значительно уменьшить объем отжираемой оперативы. Так что 5 лет тут вообще не понятно откуда взялось.

← →
@!!ex © (2007-12-15 11:53) [9]

Удалено модератором

← →
sniknik © (2007-12-15 12:04) [10]

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

← →
@!!ex © (2007-12-15 12:10) [11]

> [10] sniknik © (15.12.07 12:04)

Нет. Она просто хрнаит данные, которые требуют под себя много памяти.

← →
sniknik © (2007-12-15 12:25) [12]

> Нет. Она просто хрнаит данные, которые требуют под себя много памяти.
т.е. вариант когда "она действительно ее "жрет"", и плюс "возможно есть другой алгоритм" например не хранить в памяти, а скидывать на винт (меньше памяти за счет быстродействия).
???
подходит. так почему же "Нет"?...

← →
@!!ex © (2007-12-15 13:20) [13]

> [12] sniknik © (15.12.07 12:25)
> т.е. вариант когда "она действительно ее "жрет"", и плюс
> "возможно есть другой алгоритм" например не хранить в памяти,
> а скидывать на винт (меньше памяти за счет быстродействия)
> .

Низя. Это текстуры и они в реальном времени требуетюся несколько десятков раз в секунду.

← →
Loginov Dmitry © (2007-12-15 13:44) [14]

> У меня прога написанная за неделю жрет около 30 метров памяти,
> и я зуб даю, что какой бы не был профи, не сможет значительно
> уменьшить объем отжираемой оперативы.

Я же говорю, что это от задачи зависит сильно! Если ты представляешь, что делает твоя программа, и под что выделяется столько памяти - значит все нормально, и в данном случае винить Delphi, в том, что программа отжирает много памяти - просто некорректно! Автор видимо понятия не имеет, что делает его программа.

> Автор, ты скорее всего нахреначил бездумно компонентов,
> подключил туеву хучу юнитов

Весьма вероятно, что из-за этого. Но это не повод обвинять в расточительстве Delphi.

> Так что 5 лет тут вообще не понятно откуда взялось.

Просто за 5 лет разработки безо всяких текстур, сторонних компонентов и прочего программа до таких размеров так или иначе разрастется.

← →
{RASkov} © (2007-12-15 13:51) [15]

> Автор видимо понятия не имеет, что делает его программа.

Сильно сказано :))

← →
Rouse_ © (2007-12-15 13:53) [16]

> Тебе нужно прописывать везде Halt либо TerminateProcess(DWORD(-1), 0);

мдя... не нужно давать таких советов.

← →
Sapersky (2007-12-15 13:58) [17]

У меня прога написанная за неделю жрет около 30 метров памяти, и я зуб даю, что какой бы не был профи, не сможет значительно уменьшить объем отжираемой оперативы.

Не надо так торопиться раздавать свои зубы :)
Я же предлагал вариант не использовать оперативу вообще, а хранить всё в видеопамяти и выводить исключительно аппаратными средствами.
Собственно, даже если перегонять через системную, после создания текстуры можно сгенерировать уменьшенную копию битмапа для превью, а полноразмерную стереть.

← →
Loginov Dmitry © (2007-12-15 14:16) [18]

> Сильно сказано :))

Почему? Программа же "простейшая"! Судя по отжиранию памяти - как минимум 95% кода написано не автором, т.е. эта часть - за сторонними компонентами! Компоненты - это тоже часть программы. Но что они такого делают?

> мдя... не нужно давать таких советов.

это не совет, а замечание по поводу везде я прописываю Free либо Destroy. Мне лично страшно представить, как Free либо Destroy может быть прописано везде!

← →
@!!ex © (2007-12-15 14:36) [19]

> Не надо так торопиться раздавать свои зубы :)

НИче, я себе коронки вставлю. ;)

> Я же предлагал вариант не использовать оперативу вообще,
> а хранить всё в видеопамяти и выводить исключительно аппаратными
> средствами.

В любом случае API хранит текстуру в обычной памяти, иначе как же работают приложения, у которых загруается гиг текстур, а видюхи всего 64 метра? ;)

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

Еще раз повторяю: текстура хранится в оперативе.

← →
@!!ex © (2007-12-15 14:37) [20]

P.S.
Вернее может хранится в оперативе, если API так захочется.
НЕо вроде я это дело тестил, он вообще все текстуры туда кладет, даже если видеопамяти полно.

← →
Efir (2007-12-15 15:10) [21]

Вроде в DX при инициализации есть выбор, где хранить текстуры, в видеопамяти или в оперативной. А уж если они туда не влезают, то попадают в оперативную память.

← →
@!!ex © (2007-12-15 15:36) [22]

> [21] Efir (15.12.07 15:10)

Ща почитал, в OpenGL тоже можно, но это в конкретно данном случае ни к чему хорошему не приведет...

← →
Sapersky (2007-12-15 18:10) [23]

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

И полноразмерный битмап (TBitmap, не текстура - ещё одна копия в системной памяти) там точно лишний.

← →
@!!ex © (2007-12-15 18:43) [24]

> [23] Sapersky (15.12.07 18:10)
> Но в принципе возможность сэкономить есть - это к слову
> о "какой бы не был профи, не сможет значительно уменьшить
> объем отжираемой оперативы".

Стоп-стоп.
Любое изменение сейчас, позволяющее сэкономить память убьет производительность или качество.
Если мы не храним BitMap Для превью, то получаем невозможность нормально работать на компах без драйвера виодеокарты. Можно уменьшать BitMap програмно, или рисовать его через StretchBlt уже достаточным размером для Preview, но это опять скажется на скорости.
Мы можем сжимать текстуру для куба в 256 цветов, или просто делать меньшего разрешения, но это убьет качество. Мы можем хранить текстуры на винче(что убьет скорость) или получать их с помощью PrintWindow(что убьет скорость и отрежет старые операционки).
Так что я пока от своих слов отказаться не готов.

← →
Правильный_Вася (2007-12-15 18:48) [25]

много зависит от менеджера памяти и от режима его работы
в некоторых случаях удобно минимализмом обойтись, когда за каждым байтом менеджер будет к винде отдельно на поклон ходить
а чаще всего удобно просить побольше, все равно потом понадобиться, но уже не нужно будет кланяться винде - так ведет себя большинство менеджеров по умолчанию

← →
homm © (2007-12-15 19:50) [26]

> [14] Loginov Dmitry © (15.12.07 13:44)
> Автор видимо понятия не имеет, что делает его программа.

+1 :)

← →
Johnmen © (2007-12-15 21:57) [27]

> > Автор видимо понятия не имеет, что делает его программа.

А это не его программа.

← →
Sapersky (2007-12-16 00:06) [28]

Можно уменьшать BitMap програмно, или рисовать его через StretchBlt уже достаточным размером для Preview, но это опять скажется на скорости.

А 4 StretchBlt в TPreviewForm.FormPaint на скорости не сказываются?
StretchBlt в любом случае работает софтверно, хоть на канвас, хоть в битмап. И лучше сразу уменьшить 1 битмап, чем 4 в каждом OnPaint.
Уже экономия памяти почти в 2 раза.

Мы можем сжимать текстуру для куба в 256 цветов

Когда писал - подразумевал сжатие без потерь, но теперь думаю, что лучше всего банальный jpeg. Т.е. текстура хранится только в видео, а копия для восстановления в системной памяти сжимается в jpeg. Экономия раз в 10-15. По скорости, как ни странно, вполне прилично - картинка 1280 * 1024 на моём далеко не суперкомпьютере сжимается за 150 мс. Необязательно даже мудрить с откладыванием сжатия в OnIdle или отдельный поток.
Разницу в качестве никто, скорее всего, не заметит, тем более что восстановление текстуры требуется относительно редко.

Остапа понесло (с)

> А 4 StretchBlt в TPreviewForm.FormPaint на скорости не сказываются?
>
> StretchBlt в любом случае работает софтверно, хоть на канвас,
> хоть в битмап. И лучше сразу уменьшить 1 битмап, чем 4
> в каждом OnPaint.
> Уже экономия памяти почти в 2 раза.

В два раза - это 15 мегабайт? :)))
Дело в том, что это в разные моменты задержка. ОДна перед выводом куба(чт о не допустимо), другая - вывод на превью, что есть пофиг.

> Когда писал - подразумевал сжатие без потерь, но теперь
> думаю, что лучше всего банальный jpeg. Т.е. текстура хранится
> только в видео, а копия для восстановления в системной памяти
> сжимается в jpeg. Экономия раз в 10-15. По скорости, как
> ни странно, вполне прилично - картинка 1280 * 1024 на моём
> далеко не суперкомпьютере сжимается за 150 мс. Необязательно
> даже мудрить с откладыванием сжатия в OnIdle или отдельный
> поток.
> Разницу в качестве никто, скорее всего, не заметит, тем
> более что восстановление текстуры требуется относительно
> редко.

Чем сжимаешь?

> [30] @!!ex © (16.12.07 09:41)

Что-то правда делать 4 StretchBlt при каждом апдейте помоему непозволительная роскошь. Он медленный до жути.

← →
Sapersky (2007-12-16 13:06) [33]

В два раза - это 15 мегабайт? :)))
Дело в том, что это в разные моменты задержка. ОДна перед выводом куба(чт о не допустимо), другая - вывод на превью, что есть пофиг.

Угадал: 1280 * 1024 * 3 * 4 = ровно 15 мб. Минус какие-то копейки на уменьшенные копии битмапов.
Хотя, наверное, лучше завести один постоянный полноразмерный буфер на все десктопы, чтобы не выделять его "на лету". Тогда в 1.6 раза.

Что касается задержек - есть масса способов отложить или "размазать" их по времени. Кое-что я уже упоминал: откладывание действия в OnIdle или отдельный поток. OnIdle, кстати, проще, и для относительно коротких процессов неплохо работает. "Размазывание" - симуляция многопоточности без необходимости синхронизации и прочих заморочек, картинка разбивается, допустим, на вертикальные полоски и постепенно (по таймеру, в основном цикле) обрабатывается без заметных визуально тормозов. Хотя применительно к StretchBlt такое разбиение может дать "швы" между полосками.
Если сообщение на отрисовку придёт до завершения действия - рисовать большой битмап через StretchBlt.

Чем сжимаешь?

Intel Jpeg Library.

не. вообще фигня. когда запускал на п266 - мгновенно отрисовывалось.

Вероятно, там Win98 или NT, которые HALFTONE не поддерживают, и StretchBlt работает в режиме COLORONCOLOR, который гораздо быстрее.

> Вероятно, там Win98 или NT, которые HALFTONE не поддерживают,
> и StretchBlt работает в режиме COLORONCOLOR, который гораздо
> быстрее.

Вероятно там Win XP Prof, разрешение 800х600, 32 бита.

> [33] Sapersky (16.12.07 13:06)
> Хотя, наверное, лучше завести один постоянный полноразмерный
> буфер на все десктопы, чтобы не выделять его "на лету".
> Тогда в 1.6 раза.

Я наверное когданибудь напишу статью о вреде сохранения буфера для записи и его пагубном влиянии на производительность. По вашему выделить 5 метров в любом удобном месте для винды задача более сложная, чем достать черт знает откуда (вполне возможно из свопа) определенные конкретные 5 метров, которые нужны для того, что-бы заново их переписать?

> Что касается задержек - есть масса способов отложить или
> "размазать" их по времени. Кое-что я уже упоминал: откладывание
> действия в OnIdle или отдельный поток. OnIdle, кстати, проще,
> и для относительно коротких процессов неплохо работает.
> "Размазывание" - симуляция многопоточности без необходимости
> синхронизации и прочих заморочек, картинка разбивается,
> допустим, на вертикальные полоски и постепенно (по таймеру,
> в основном цикле) обрабатывается без заметных визуально
> тормозов. Хотя применительно к StretchBlt такое разбиение
> может дать "швы" между полосками.
> Если сообщение на отрисовку придёт до завершения действия
> - рисовать большой битмап через StretchBlt.

Что даст многопоточность на старых одноядерных машинах(а основываться как раз приходиться на эти машины)

> Что даст многопоточность на старых одноядерных машинах

Распараллеливание работы ? Я угадал ?

← →
Sapersky (2007-12-17 18:29) [38]

Я наверное когданибудь напишу статью о вреде сохранения буфера для записи и его пагубном влиянии на производительность. По вашему выделить 5 метров в любом удобном месте для винды задача более сложная, чем достать черт знает откуда (вполне возможно из свопа) определенные конкретные 5 метров, которые нужны для того, что-бы заново их переписать?

Полагаю, зависит от частоты использования буфера. Если он используется относительно редко - да, возможно, лучше выделять "на лету". Если часто - предпочту выделить заранее; попадёт ли этот буфер в своп - ещё неизвестно, а вот некоторое (пусть небольшое) замедление от постоянного выделения/освобождения памяти будет обязательно.
В случае WinDesk я не вполне уверен, поэтому и написал в [33] "наверное". Может быть, лучше и "на лету", т.к. это скорее "редкое" использование. Но меня смущает TBitmap, который славен тем, что норовит к самой простой операции прицепить кучу "самодеятельности".

Что даст многопоточность на старых одноядерных машинах(а основываться как раз приходиться на эти машины)

Возможность утилизировать резервы мощности, которые возникают при "простоях" приложения. В играх никаких простоев и резервов нет, но при работе событийно-ориентированного приложения загрузка CPU неравномерна, график имеет вид ряда пиков и почти полных провалов между ними. "Размазав" эти пики по времени, можно получить меньшее время отклика на действия пользователя и субъективно более быструю программу, хотя реально производительность не увеличивается.
Для начала рекомендую OnIdle как упрощённый вариант. Срабатывает именно при "простое" и вполне пригодно для выполнения не очень длительного действия (задержку в 100-200 мс пользователь не почувствует). Не требует синхронизации.

> попадёт ли этот буфер в своп - ещё неизвестно, а вот некоторое
> (пусть небольшое) замедление от постоянного выделения/освобождения
> памяти будет обязательно.

Видишь ли выделение памяти, в многозадачных системах с контролем доступа, - это ОЧЧЧЕНЬ медленная процедура. Менеджер памяти в Delphi, очень грамотен и поэтому, это не сильно заметно. Поиграйся с глобальной памятью - поймешь почему photoshop при старте под себя хапает, то что указано в конфигах, и использует собственный своп, стараясь игнорировать системный.

> [39] tesseract © (17.12.07 21:24)
> Видишь ли выделение памяти, в многозадачных системах с контролем
> доступа, - это ОЧЧЧЕНЬ медленная процедура.

Очень медленная… Ну ОЧЕНЬ медленная…

procedure TForm1.Button1Click(Sender: TObject); var T,i: Integer; p: THandle; begin T := GetTickCount(); try for i := 0 to 225000 do begin P := GlobalAlloc(GMEM_FIXED, 5*1024*1024); GlobalFree(P); end; finally ShowMessage(IntToStr(GetTickCount-T)); end; end;

Целых 0,000004(4) секунды на одну такую операцию уходит. А теперь представь, что память тки попала в своп за 4 секунды, что работали другие приложения…

> Но меня смущает TBitmap, который славен тем, что норовит
> к самой простой операции прицепить кучу "самодеятельности".

Вот тут согласен полностью.

> Поиграйся с глобальной памятью - поймешь почему photoshop
> при старте под себя хапает

Неа, не понял :( Фотошоп у меня вообще при каждом старте ругается, что у меня подкачка отключена. Дурень, ему не ведомо, что у меня 2 гектара :)

Уменьшение ресурсов! Найти похожие ветки