Освобождение памяти занимаемой объектом

[Oburec]

вызываю деструктор класса, память не освобождается. У класса в полях записаны массивы данных (SetLength). Пишу тестовый пример, память освободждается, в основном приложении нет. Если кто сталкивался - намекните, хоть в какую сторону копать...
в отладчике попадаю в деструктор объекта, при этом ни байта не освобождается. делал setlength(0) на массивы внутри класса, хотя и так должно освобождать, все равно не помогает...

[Пепел Феникса]

1)код в студию
2)чем память проверяешь?

[BOBAH13]

Как я понял из опыта, если есть еще память в системе свободная и не требуется другим приложениям, сервисам и т.п. то Windows (система) "физически" (через диспетчер задач) не освобождает память, а как бы удаляет те объекты, кучи и т.п. из того места в памяти. Зачем ? Да наверное чтобы если потом вы запросите из кучи несколько байт, то они уже будут в вашем распоряжении, поидеи это сделано для увеличения скорости работы приложения
Ну это я нигде не читал, просто работал с огромным кол-вом памяти и заметил такую зависимость.
p.s. особенно это заметно когда выделяются мегабайты памяти

Это все при том что ваш код идеален а вдруг вы там ошибочку сделали.

[rpy3uH]

Сообщение от BOBAH13

Как я понял из опыта, если есть еще память в системе свободная и не требуется другим приложениям, сервисам и т.п. то Windows (система) "физически" (через диспетчер задач) не освобождает память, а как бы удаляет те объекты, кучи и т.п. из того места в памяти. Зачем ? Да наверное чтобы если потом вы запросите из кучи несколько байт, то они уже будут в вашем распоряжении, поидеи это сделано для увеличения скорости работы приложения

совершенно верно.
Главные функции выделения памяти это функции VirtualAlloc/VirtualFree. Без них никуда. Но у них большая гранулярность выделения - 64 КБ. Для оптимизации выделения маленьких кусков памяти были созданы диспетчеры куч. Когда мы юзаем функции new/dispose, GetMem/FreeMem, SetLength и в конце концов API HeapAlloc/HeapFree мы обращаемся к разным диспетчерам куч. Они выделяют память с гранулярностью 8-16 байт. Принцип их работы прост: сначала выделяется большой кусок памяти, а потом маленькими кусочками он распределяется между потоками, подпрограммами и прочим.
Поэтому при освобождении памяти через dispose, FreeMem и другими потребление памяти программой не уменьшается.

[Oburec]

Сообщение от Пепел Феникса

1)код в студию
2)чем память проверяешь?

есть самодельний 3д двиг, в процессе удаления объектов вызывается например такой деструктор

Destructor cMesh.Destroy;
begin
 setlength(VertexArray,0);
 setlength(NormalsArray,0);
 setlength(TexVertexArray,0);
 inherited;
end;

Это просто для примера. массивы вершин бывают довольно большими
Память выделяется как SetLength либо Create классов, которые хранятся в списках. Никаких других способов выделения памяти не применяется. Смотрю память в диспетчере задач, и еще так пытался:

function GetProcMem:cardinal;
var
  pmc: PPROCESS_MEMORY_COUNTERS;
  cb: Integer;
begin
  cb := SizeOf(_PROCESS_MEMORY_COUNTERS);
  GetMem(pmc, cb);
  pmc^.cb := cb;
  if GetProcessMemoryInfo(GetCurrentProcess, pmc, cb) then
    result:= pmc^.WorkingSetSize;
  FreeMem(pmc);
end;

В тестовых примерах все нормально освобождается, а в самом проекте фигня какая-то.

Сообщение от BOBAH13

Как я понял из опыта, если есть еще память в системе свободная и не требуется другим приложениям, сервисам и т.п. то Windows (система) "физически" (через диспетчер задач) не освобождает память, а как бы удаляет те объекты, кучи и т.п. из того места в памяти...

Ну и как тогда вообще отлаживаться? Всмысле как проверить есть утечки или нет...

[rpy3uH]

Сообщение от Oburec

Ну и как тогда вообще отлаживаться? Всмысле как проверить есть утечки или нет...

если утечка есть, то это сразу понятно, программа начинает жрать много памяти.

[BOBAH13]

Да, и то что я привел, это не есть утечка, это фича системы Windows. Так что не очем беспокоится, Вам, если и будут напряги система будет вынуждена "реально" отрезать от вас кусочек памяти

[alexBlack]

Сообщение от Oburec

Ну и как тогда вообще отлаживаться? Всмысле как проверить есть утечки или нет...

Для проверки можно использовать GetHeapStatus:

var BeginHeap, EndHeap : THeapStatus;
begin
    BeginHeap := GetHeapStatus;

    // операция

    EndHeap := GetHeapStatus;
    LostMemory := (EndHeap.TotalAllocated - BeginHeap.TotalAllocated);

Для большинства случаев это нормально работает. Неправильно учитывается автоматическое распределение (например, для строк), но такие места легко исключить из проверки.

Выключаем проверку:
SavedMemory := GetHeapStatus.TotalAllocated // запомнили текущее состояние

Включаем снова
CorrectMem += (GetHeapStatus.TotalAllocated - SavedMemory); // неучитываемая память

А в конце:
LostMemory := (EndHeap.TotalAllocated - BeginHeap.TotalAllocated) - CorrectMem;

Если это оформить в виде класса, получается удобный инструмент для отладки.

[rpy3uH]

Сообщение от alexBlack

Для проверки можно использовать GetHeapStatus:

всё вроде бы хорошо и удобно. Но нельзя забывать что диспетчеры куч Delphi и C++ работают по своему, в обход функций Heap***. Не знаю как Delphi, но в С++ точно свой диспетчер куч (проверял на Visual C++ 6.0).

[JTG]

В простейшем случае установить ReportMemoryLeaksOnShutdown = true, тогда программа при завершении скажет сколько байт не освободила и какой тип/класс виноват. В 7й делфе этого нет