| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Проблемы с диспетчером памяти..? [D5, Win2k]
arm79 © (2004-08-05 18:14:00)Уважаемые мастера! Возникла неприятная ситуация с размерами занимаемой моей программой памяти. Работа идет с большим кол-вом списков и элементов в нем. Часто приходится удалять эти элемены и списки. На первый взгляд выделение и очистка памяти написаны корректно. Выдаваемые данные не искажаются, программа работает, функции выполняет. Но к концу дня "жрет" виртуальной памяти под гигабайт. В связи с этим вопрос, а высвобождаемое место при FreeMem повторно используется? Или виндовый диспетчер памяти не хочет увидеть кусочки такой памяти свободными? То есть я просто хочу знать, это моя прога однозначно виновата(в том плане, что я где то забываю освободить память) или есть вероятность, что диспетчер памяти в Win2000 некорректно работает? Программу приводить не буду, она слишком объемная, но если кто хочет, могу переслать по почте модуль, в котором идет работа со списками.
ЗЫ Удаляемые списки содержат указатели на целые числа. При удалении таких списков я сначала освобождаю память, на которую ссылаются элементы списка, потом вызываю метод Clear + FreeAndNil (или Free)
Дуся (2004-08-10 10:57:00) [1]Всем спасибо!!..
Убрали многочисленные GetMem/FreeMem
Сделали интегеры typecast в pointerы.
Результат - потери полностью прекратились!!
Делаем выводы.
Германн (2004-08-10 03:51:00) [2]2 Seldon © (06.08.04 21:59) [27]
> А если моя программа в при старте загружает в TList ОГРОМНОЕ количество данных...
Первый раз слышу, что в TList загружается "ОГРОМНОЕ количество данных". Обычно, в него загружается весьма небольшой список указателей. А уж сколько занимают памяти те структуры, на которые указывают элементы TList.Items - это уже другой вопрос! И (TList.Clear;TList.Free) ни в коей мере не освобождают ее!
Seldon (2004-08-09 21:26:00) [3]
> [29] Digitman © (09.08.04 14:35)
>
> > Seldon © (06.08.04 21:59) [27]
>
>
> ты что-нибудь про механизм подкачки хоть краем уха слышал
> ? или для тебя это пустой звук ?
Самым краешком.
delphi2002 (2004-08-09 17:37:00) [4]>arm79
Пришли код.
Подивлюся.
Може знайду помилку :)
delphi2002@ukr.net
Digitman (2004-08-09 14:35:00) [5]
> Seldon © (06.08.04 21:59) [27]
ты что-нибудь про механизм подкачки хоть краем уха слышал ? или для тебя это пустой звук ?
Дуся (2004-08-09 14:31:00) [6]Seldon ©
Признаться, я тоже хотела бы услышать четкий ответ на этот вопрос..
Seldon (2004-08-06 21:59:00) [7]
> пока процесс существует - да, ресурсы, ассоциированные с
> блоками, не отданными в кучу, не могут быть использованными
> другими процессами
А если моя программа в при старте загружает в TList ОГРОМНОЕ количество данных, работает с ними, потом освобождает память, занимаемую этими данными (TList.Clear;TList.Free) и в процессе дальнейшей работы не нуждается в таком ОГРОМНОМ количестве памяти, то вся память, выделенная при начальной обработке данных, будет недоступна другим процессам до окончания работы моей программы?
GuAV (2004-08-06 16:43:00) [8]2 Дуся
> т.е. вы думаете, что если мы, к примеру, возьмем TStringList
> и наши цифирки зафигачим не в объекты, а просто в строки,
> то будет нам счастье?
имхо:
TList - если индексы по порядку. Items - интегеры typecast в pointerы
TBucketList из Unit Contnrs - если ассоцииировать Integer или Pointer с другим Integer или Pointer. опять же интегеры typecast в pointerы. TStringList не при чем.
Digitman (2004-08-06 16:32:00) [9]
> TUser
можно сказать, что "кучевой" механизм, интерфейс которого представлен набором ф-ций HeapAlloc/Realloc/Free (и еще некот. специальных) так же есть своего рода механизм "менеджера памяти" ... в ряде случаев им можно воспользоваться и напрямую, минуя ВММ, но в этом случае ВММ не несет никакой ответственности за результаты распределения ресурсов при таких прямых обращениях со стороны прикл.кода
Digitman (2004-08-06 16:21:00) [10]
> TUser
он (ВММ) поэтому и называется "менеджером памяти", потому что осуществляет посредничество между "поставщиком ресурсов" - кучей - и твоей прикладной задачей, нуждающейся не в каких-то там "кучах", а в гарантиях , что для хранения некоей инф-ции менеджер по ее запрпосу предоставил гарантированно существующий в ВАП процесса фиксированный диапазон адресов
Digitman (2004-08-06 16:15:00) [11]
> TUser © (06.08.04 16:09) [22]
да не трогай ты хип ! не нужно тебе туда лезть ! ВММ сам разберется, когда и как с кучей работать... твое дело - при обращениях к ВММ соблюдать баланс между запросами блоков у него и соотв.отдачей ему этих блоков
если же баланс этот ты не соблюдаешь (т.е. суммарно запрошенная по GetMem память не соответствует суммарно оттданной по Freemem), то БММ будет вынужден запрашивать из кучи все новые и новые блоки, тем самым бестолково наращивая занимаемые у ОС твоим процессом ресурсы
TUser (2004-08-06 16:09:00) [12]А если поцесс у меня работает много дней и ночей без перезапуска, то только одного FreeMem, получается, недостаточно, надо HeapFree? Кажется с начнаю понимать некоторые свои ошибки ...
Digitman (2004-08-06 16:04:00) [13]
> Так?
не так
> У процесса есть своя куча
есть.
одна.
по умолчанию.
м.б. и больше, если процесс явно запросил доп.кучи в ходе работы
как только процесс перестает существовать, перестают существовать и кучи, ассоциированные системой с процессом.
все ресурсы, ассоциированные с уничтоженными кучами, автоматически освобождаются
> память туда можно только забрать, но нельзя вернуть
вернуть можно.
на то есть ф-ция HeapFree()
если ты явно запросил вызовом HeapAlloc() блок из кучи, то возврати его назад вызовом HeapFree(), когда он более не нужен, если не хочешь утечек памяти ... утечка памяти - понятие локальное для процесса, ибо как только процесс перестает существовать, все занятые им ресурсы автоматически освобождаются, ВНЕ зависимости выполнил ты HeapFree() или забыл
Даже если ему эта память не нужна, то получается, что другие поцессы не смогут ее использовать
пока процесс существует - да, ресурсы, ассоциированные с блоками, не отданными в кучу, не могут быть использованными другими процессами
TUser (2004-08-06 15:54:00) [14]2 [8] и [9]
Т.е. так и получается. У процесса есть своя куча, но память туда можно только забрать, но нельзя вернуть. Т.о. если процесс запустился в момент t0, то в момент t под него будет выделено памяти ровно максимальное количество, которое ему требовалось за все вемя работы. Даже если ему эта память не нужна, то получается, что другие поцессы не смогут ее использовать. Потому что при освобождении памяти она вернется в кучу, а ОС по-прежнему считает ее занятой. Так?
PS. Извиняюсь, что пытаюся разобраться с этим в чужой ветке.
Дуся (2004-08-06 14:58:00) [15]Спасибо. Этого я и боялась :)
Digitman (2004-08-06 14:53:00) [16]уж не знаю насчет "счастья", но как минимум фрагментированность структур БММ можно ощутимо минимизировать ... и алгоритм существенно упростится, что даст возможность легче находить свои ошибки
Дуся (2004-08-06 14:47:00) [17]т.е. вы думаете, что если мы, к примеру, возьмем TStringList и наши цифирки зафигачим не в объекты, а просто в строки, то будет нам счастье?
Digitman (2004-08-06 14:45:00) [18]
> Дуся (06.08.04 14:34) [14]
> Ну вот так вот сделали.. Динамические массивы индексов...
и оч криво сделали, imho
на то есть как минимум классы-наследники TList - они весьма эффективно и прозрачно управляются с памятью ... главное - следить за вызовом конструкторов/диструкторов
Дуся (2004-08-06 14:38:00) [19]вкратце - есть огромные динамические списки, есть списки с индексами для ускорения поиска, т.к. система критична по времени...
в процессе поиска формуруются временные списки с индексами найденных строк.
вот при их формировании-удалении и получается такая байда..
Дуся (2004-08-06 14:34:00) [20]Ну вот так вот сделали.. Динамические массивы индексов...
| |
Страницы: 