| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Уменьшение ресурсов! [D7, XP]
NaRuTo © (2007-12-14 22:35:00)Я знаю что программы написанные на Delphi очень много забирают ресурсов компьютера, вот например моя простенькая программа в ОЗУ: занимает 32 MB, как другие программы более мощнее моей меньше раза в 2, а то и в 3. Хотя везде я прописываю Free либо Destroy;
Вопрос: Можно ли-уменьшить потребляемость моей программы ресурсов.
homm (2007-12-17 22:26:00) [1]> [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 гектара :)
tesseract (2007-12-17 21:24:00) [2]
> попадёт ли этот буфер в своп - ещё неизвестно, а вот некоторое
> (пусть небольшое) замедление от постоянного выделения/освобождения
> памяти будет обязательно.
Видишь ли выделение памяти, в многозадачных системах с контролем доступа, - это ОЧЧЧЕНЬ медленная процедура. Менеджер памяти в Delphi, очень грамотен и поэтому, это не сильно заметно. Поиграйся с глобальной памятью - поймешь почему photoshop при старте под себя хапает, то что указано в конфигах, и использует собственный своп, стараясь игнорировать системный.
Sapersky (2007-12-17 18:29:00) [3]Я наверное когданибудь напишу статью о вреде сохранения буфера для записи и его пагубном влиянии на производительность. По вашему выделить 5 метров в любом удобном месте для винды задача более сложная, чем достать черт знает откуда (вполне возможно из свопа) определенные конкретные 5 метров, которые нужны для того, что-бы заново их переписать?
Полагаю, зависит от частоты использования буфера. Если он используется относительно редко - да, возможно, лучше выделять "на лету". Если часто - предпочту выделить заранее; попадёт ли этот буфер в своп - ещё неизвестно, а вот некоторое (пусть небольшое) замедление от постоянного выделения/освобождения памяти будет обязательно.
В случае WinDesk я не вполне уверен, поэтому и написал в [33] "наверное". Может быть, лучше и "на лету", т.к. это скорее "редкое" использование. Но меня смущает TBitmap, который славен тем, что норовит к самой простой операции прицепить кучу "самодеятельности".
Что даст многопоточность на старых одноядерных машинах(а основываться как раз приходиться на эти машины)
Возможность утилизировать резервы мощности, которые возникают при "простоях" приложения. В играх никаких простоев и резервов нет, но при работе событийно-ориентированного приложения загрузка CPU неравномерна, график имеет вид ряда пиков и почти полных провалов между ними. "Размазав" эти пики по времени, можно получить меньшее время отклика на действия пользователя и субъективно более быструю программу, хотя реально производительность не увеличивается.
Для начала рекомендую OnIdle как упрощённый вариант. Срабатывает именно при "простое" и вполне пригодно для выполнения не очень длительного действия (задержку в 100-200 мс пользователь не почувствует). Не требует синхронизации.
Игорь Шевченко (2007-12-17 11:06:00) [4]
> Что даст многопоточность на старых одноядерных машинах
Распараллеливание работы ? Я угадал ?
@!!ex (2007-12-16 13:26:00) [5]> Что касается задержек - есть масса способов отложить или
> "размазать" их по времени. Кое-что я уже упоминал: откладывание
> действия в OnIdle или отдельный поток. OnIdle, кстати, проще,
> и для относительно коротких процессов неплохо работает.
> "Размазывание" - симуляция многопоточности без необходимости
> синхронизации и прочих заморочек, картинка разбивается,
> допустим, на вертикальные полоски и постепенно (по таймеру,
> в основном цикле) обрабатывается без заметных визуально
> тормозов. Хотя применительно к StretchBlt такое разбиение
> может дать "швы" между полосками.
> Если сообщение на отрисовку придёт до завершения действия
> - рисовать большой битмап через StretchBlt.
Что даст многопоточность на старых одноядерных машинах(а основываться как раз приходиться на эти машины)
homm (2007-12-16 13:20:00) [6]> [33] Sapersky (16.12.07 13:06)
> Хотя, наверное, лучше завести один постоянный полноразмерный
> буфер на все десктопы, чтобы не выделять его "на лету".
> Тогда в 1.6 раза.
Я наверное когданибудь напишу статью о вреде сохранения буфера для записи и его пагубном влиянии на производительность. По вашему выделить 5 метров в любом удобном месте для винды задача более сложная, чем достать черт знает откуда (вполне возможно из свопа) определенные конкретные 5 метров, которые нужны для того, что-бы заново их переписать?
@!!ex (2007-12-16 13:19:00) [7]> Вероятно, там Win98 или NT, которые HALFTONE не поддерживают,
> и StretchBlt работает в режиме COLORONCOLOR, который гораздо
> быстрее.
Вероятно там Win XP Prof, разрешение 800х600, 32 бита.
Sapersky (2007-12-16 13:06:00) [8]В два раза - это 15 мегабайт? :)))
Дело в том, что это в разные моменты задержка. ОДна перед выводом куба(чт о не допустимо), другая - вывод на превью, что есть пофиг.
Угадал: 1280 * 1024 * 3 * 4 = ровно 15 мб. Минус какие-то копейки на уменьшенные копии битмапов.
Хотя, наверное, лучше завести один постоянный полноразмерный буфер на все десктопы, чтобы не выделять его "на лету". Тогда в 1.6 раза.
Что касается задержек - есть масса способов отложить или "размазать" их по времени. Кое-что я уже упоминал: откладывание действия в OnIdle или отдельный поток. OnIdle, кстати, проще, и для относительно коротких процессов неплохо работает. "Размазывание" - симуляция многопоточности без необходимости синхронизации и прочих заморочек, картинка разбивается, допустим, на вертикальные полоски и постепенно (по таймеру, в основном цикле) обрабатывается без заметных визуально тормозов. Хотя применительно к StretchBlt такое разбиение может дать "швы" между полосками.
Если сообщение на отрисовку придёт до завершения действия - рисовать большой битмап через StretchBlt.
Чем сжимаешь?
Intel Jpeg Library.
не. вообще фигня. когда запускал на п266 - мгновенно отрисовывалось.
Вероятно, там Win98 или NT, которые HALFTONE не поддерживают, и StretchBlt работает в режиме COLORONCOLOR, который гораздо быстрее.
@!!ex (2007-12-16 11:25:00) [9]> [31] homm © (16.12.07 09:45)
не. вообще фигня. когда запускал на п266 - мгновенно отрисовывалось.
homm (2007-12-16 09:45:00) [10]> [30] @!!ex © (16.12.07 09:41)
Что-то правда делать 4 StretchBlt при каждом апдейте помоему непозволительная роскошь. Он медленный до жути.
@!!ex (2007-12-16 09:41:00) [11]> А 4 StretchBlt в TPreviewForm.FormPaint на скорости не сказываются?
>
> StretchBlt в любом случае работает софтверно, хоть на канвас,
> хоть в битмап. И лучше сразу уменьшить 1 битмап, чем 4
> в каждом OnPaint.
> Уже экономия памяти почти в 2 раза.
В два раза - это 15 мегабайт? :)))
Дело в том, что это в разные моменты задержка. ОДна перед выводом куба(чт о не допустимо), другая - вывод на превью, что есть пофиг.
> Когда писал - подразумевал сжатие без потерь, но теперь
> думаю, что лучше всего банальный jpeg. Т.е. текстура хранится
> только в видео, а копия для восстановления в системной памяти
> сжимается в jpeg. Экономия раз в 10-15. По скорости, как
> ни странно, вполне прилично - картинка 1280 * 1024 на моём
> далеко не суперкомпьютере сжимается за 150 мс. Необязательно
> даже мудрить с откладыванием сжатия в OnIdle или отдельный
> поток.
> Разницу в качестве никто, скорее всего, не заметит, тем
> более что восстановление текстуры требуется относительно
> редко.
Чем сжимаешь?
Johnmen (2007-12-16 00:28:00) [12]Остапа понесло (с)
Sapersky (2007-12-16 00:06:00) [13]Можно уменьшать BitMap програмно, или рисовать его через StretchBlt уже достаточным размером для Preview, но это опять скажется на скорости.
А 4 StretchBlt в TPreviewForm.FormPaint на скорости не сказываются?
StretchBlt в любом случае работает софтверно, хоть на канвас, хоть в битмап. И лучше сразу уменьшить 1 битмап, чем 4 в каждом OnPaint.
Уже экономия памяти почти в 2 раза.
Мы можем сжимать текстуру для куба в 256 цветов
Когда писал - подразумевал сжатие без потерь, но теперь думаю, что лучше всего банальный jpeg. Т.е. текстура хранится только в видео, а копия для восстановления в системной памяти сжимается в jpeg. Экономия раз в 10-15. По скорости, как ни странно, вполне прилично - картинка 1280 * 1024 на моём далеко не суперкомпьютере сжимается за 150 мс. Необязательно даже мудрить с откладыванием сжатия в OnIdle или отдельный поток.
Разницу в качестве никто, скорее всего, не заметит, тем более что восстановление текстуры требуется относительно редко.
Johnmen (2007-12-15 21:57:00) [14]
> > Автор видимо понятия не имеет, что делает его программа.
А это не его программа.
homm (2007-12-15 19:50:00) [15]> [14] Loginov Dmitry © (15.12.07 13:44)
> Автор видимо понятия не имеет, что делает его программа.
+1 :)
Правильный_Вася (2007-12-15 18:48:00) [16]много зависит от менеджера памяти и от режима его работы
в некоторых случаях удобно минимализмом обойтись, когда за каждым байтом менеджер будет к винде отдельно на поклон ходить
а чаще всего удобно просить побольше, все равно потом понадобиться, но уже не нужно будет кланяться винде - так ведет себя большинство менеджеров по умолчанию
@!!ex (2007-12-15 18:43:00) [17]> [23] Sapersky (15.12.07 18:10)
> Но в принципе возможность сэкономить есть - это к слову
> о "какой бы не был профи, не сможет значительно уменьшить
> объем отжираемой оперативы".
Стоп-стоп.
Любое изменение сейчас, позволяющее сэкономить память убьет производительность или качество.
Если мы не храним BitMap Для превью, то получаем невозможность нормально работать на компах без драйвера виодеокарты. Можно уменьшать BitMap програмно, или рисовать его через StretchBlt уже достаточным размером для Preview, но это опять скажется на скорости.
Мы можем сжимать текстуру для куба в 256 цветов, или просто делать меньшего разрешения, но это убьет качество. Мы можем хранить текстуры на винче(что убьет скорость) или получать их с помощью PrintWindow(что убьет скорость и отрежет старые операционки).
Так что я пока от своих слов отказаться не готов.
Sapersky (2007-12-15 18:10:00) [18]Хранение копии в системной памяти - наиболее простой метод борьбы с "потерей" текстуры при переключении другого приложения в полноэкранный режим или при нажатии Ctrl-Alt-Del в Win2000. Но наиболее простой - не значит единственный, например, можно попробовать восстанавливать изображение десктопа через PrintWindow и т.п., или хранить копию, но в сжатом виде. Другое дело, что выгода от подобных трюков, учитывая современные объёмы ОП, довольно сомнительна. Но в принципе возможность сэкономить есть - это к слову о "какой бы не был профи, не сможет значительно уменьшить объем отжираемой оперативы".
И полноразмерный битмап (TBitmap, не текстура - ещё одна копия в системной памяти) там точно лишний.
@!!ex (2007-12-15 15:36:00) [19]> [21] Efir (15.12.07 15:10)
Ща почитал, в OpenGL тоже можно, но это в конкретно данном случае ни к чему хорошему не приведет...
Efir (2007-12-15 15:10:00) [20]Вроде в DX при инициализации есть выбор, где хранить текстуры, в видеопамяти или в оперативной. А уж если они туда не влезают, то попадают в оперативную память.
| |
Страницы: 