Есть программа оперирующая большим числом объектов и структур (несколько миллионов).
Такое количество объектов оправдано - там модель энергосистемы состоящей из тысяч подстанций вместе с их оборудованием, графическим представлением, топологией, состоянием, режимом. Модель в памяти занимает порядка гигабайта (там показывают диспетчер задачи и Process Explorer ). Кроме того, может быть обращение к временным объектам через интерфейсы типа TInterfacedObject, которые удаляются при выходе из области видимости.
Используюся парсеры XML (DIXML), объемы файлов данных несколько десятков мегабайт, на время чтения и построения XML DOM объем памяти может возрастать на пару сотен метров, но потом уменьшается.

Нужно сократить объем занимаемой памяти. Для этого понять, какие объекты или структуры заминают существенную часть и постепенно оптимизировать.
Для этого написал модуль, который бегает по всем объектам и собирает статистику использования памяти по классам по RTII через SizeOf , с учетом размеров динамических массивов и строк (они прибавляются). Вот результат работы.
https://disk.yandex.ru/d/bY5hSPlnn3DTLA
Еще пользовался программой Deleaker, на относительно малых объемах (200-300 Мб) она показывала сопоставимые с моим модулем результаты. Ну а на объемах в гигабайт она просто дохнет.
Но модуль показывает не то, что диспетчер задач. Тут 150 Мб, в диспетчере 1,2 Гб. Нужно понять чем забита программа. То, что диспетчер задач показывает "не то" я в курсе.
За учечками памяти следим, FastMM показывает на выходе не более нескольких десятков неосвобожденных объектов, но не миллионы.
Хотелось бы как то посмотреть чем физически занята куча. какого класса объекты (классы, рекорды, динамические массивы, строки, битмапы) где расположены, живые ли. Есть идеи как?

asviridenkov,

Знаю, были оптимизированы порядка пяти самых массовых классов, которые были переделаны на более компактные рекорды, уменьшено количество использованных экземпляров, память уменьшена на 30-40%. НА все рефакторинги, связанные с этим было потрачено порядка человеко - года. И есть планы дальнейшей оптимизации. Это потребует огромной работы, существенной переделки объектных моделей, несколько человеко-лет. НО те классы отображались в моем отчете. А тут теперь непонятно, что вообще жрет память.

Fr0sT-Brutal,



Поставил AQTime из магазина, вообще не пашет. ТО говорит нет exe, то нет debug информации.

Про это и был вопрос. Как мониторить подобные ресурсы в куче. Растры там есть, но не так много, XML освобождается после чтения, это видно по диспетчеру.

[quot Fr0sT-Brutal#22414818]Поставить FastMM полноценный из репо, а не комплектный, у него есть методы запроса всей текущей кучи. Или как минимум можно запросить общий выделенный объем и сравнить его с показаниями диспетчера. Надо помнить, что FastMM
Отдельный полный FastMM конечно стоит, но только штатными отчетами пользовался, в API не разбирался. Несколько дней или недель сейчас тратить некогда.


Совсем не получится, так несколько утечек встроено в дельфи и сторонние компоненты типа девэкспресса.
Наших сравнимое с ними количество.


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



Такое требование есть по факту, но тут гигабайт жрет 1 документ, а нужно держать их несколько одновременно открытыми в одном 32 разрядном процессе, на процесс отведено 3 Гб. Можно попробовать и 64 разрядное приложение, но если так разбрасываться памятью, то надо будет требовать по 32 или 64.

Нужно держать одновременно открытыми несколько больших документов, или документ динамически Собранный из многих маленьких.
Были эксперименты держать каждый документ в своем процессе, как вкладки в браузере, но архитектурно это намного, намного сложнее.