Проблема заключается в следующем:
Есть прога — модель СМО(ситсемы массового обслуживания) а конкретно модель СУБД.
Все прекрасно работает без исключений и прочее.
Моделирование: все элементы модели Объкты дерево. Динамически путем копирования создаются структуры типа запросы, которые далее удаляются в одном из блоков. Удаляется все тоже по правилам по всем. НО полсе создания примерно 450 000 штук запросов(объектов типа запрос) размер ОП выделяемой программой увеличивается на 120 М получается что структура размером 300 байт не удаляется вопреки ожиданиям. После завершения программы размер свободной ОП восстанавливается.
Т.е. я понимаю что после вызова деструктора память не освобождаемтся.
Я так понимаю, все объекты типа наслеуемые от TObject являются динамичесмкими — размещаются в "КУЧЕ". Если не так поправьте меня.

Вопрос каким образом заставить ОС или программу освобождать память после удаления объектов.

Здравствуйте, vedmalex, Вы писали:

V>Проблема заключается в следующем:
V>Есть прога — модель СМО(ситсемы массового обслуживания) а конкретно модель СУБД.
V>Все прекрасно работает без исключений и прочее.
V>Моделирование: все элементы модели Объкты дерево. Динамически путем копирования создаются структуры типа запросы, которые далее удаляются в одном из блоков. Удаляется все тоже по правилам по всем. НО полсе создания примерно 450 000 штук запросов(объектов типа запрос) размер ОП выделяемой программой увеличивается на 120 М получается что структура размером 300 байт не удаляется вопреки ожиданиям. После завершения программы размер свободной ОП восстанавливается.
V>Т.е. я понимаю что после вызова деструктора память не освобождаемтся.
V>Я так понимаю, все объекты типа наслеуемые от TObject являются динамичесмкими — размещаются в "КУЧЕ". Если не так поправьте меня.

V>Вопрос каким образом заставить ОС или программу освобождать память после удаления объектов.

Всё правильно, они именно там и размещаются. Если у тебя объекты одного типа и их много, как раз как в твоём случае, то логичнее
использовать (и самому в этом случае управлять) виртуальную
память — это функции VirtualAlloc(...), VirtualFree. С ними по крайней мере ты сам резервируешь регион, сам коммитишь память и сам же её
возвращаешь системе и освобждаешь регион. (Возьми книжку Дж. Рихтер "Создание эффективных Win32 приложений" там про
это всё отлично расписано).

Удачи!

>Я так понимаю, все объекты типа наслеуемые от TObject являются динамичесмкими — размещаются в "КУЧЕ". Если не так >поправьте меня.

Смотря что понимать под кучей.
Если стандартную виндовскую кучу — то нет.
У Борланда свой менеджер памяти, который получает память непосредственно у
системы через VirtualAlloc и сам решает, когда возвратить её системе.
Чесно говоря, я слабо представляю, как можно заставить стандартный менеджер форсировать это действие,
кроме как использовать другой менеджер.
(Или перекрыть InitInstance/FreeInstance для запроса).

А структуры там ещё откуда — это место я не понял.

Здравствуйте, Аноним, Вы писали:

А>Всё правильно, они именно там и размещаются. Если у тебя объекты одного типа и их много, как раз как в твоём случае, то логичнее
А>использовать (и самому в этом случае управлять) виртуальную
А>память — это функции VirtualAlloc(...), VirtualFree. С ними по крайней мере ты сам резервируешь регион, сам коммитишь память и сам же её
А>возвращаешь системе и освобждаешь регион. (Возьми книжку Дж. Рихтер "Создание эффективных Win32 приложений" там про
А>это всё отлично расписано).

А>Удачи!

Спасибо, в общем понятно каким образом дейсвтовать.
Ок Буду искать варианты.

Здравствуйте, Аноним, Вы писали:

А>А структуры там ещё откуда — это место я не понял.

я честно говоря сам не понял, просто выделяется память и все под динамический объект типа class,
да я почитал доки — память освобождается автоматически после удаления объекта — вызова методов destroy/free.
т.е. я понял это просто несовершенство разработки.

Здравствуйте, vedmalex, Вы писали:

модель запускается в отдельном потоке — может эта трабла из-за этого??
Хотя я вообще то сомневаюсь.

Ну всем спасибо буду искать дальше.

Здравствуйте, vedmalex, Вы писали:

V>модель запускается в отдельном потоке — может эта трабла из-за этого??
V>Хотя я вообще то сомневаюсь.

И я тоже сомневаюсь. Исполнение в потоке могло только усугубить
уже существующие проблемы.

V>Ну всем спасибо буду искать дальше.

А что, собс-но, ты ищешь?

--
С уважением, LVT.

Здравствуйте, vedmalex, Вы писали:
V>Есть прога — модель СМО(ситсемы массового обслуживания) а конкретно модель СУБД.
V>Все прекрасно работает без исключений и прочее.
V>Моделирование: все элементы модели Объкты дерево. Динамически путем копирования создаются структуры типа запросы, которые далее удаляются в одном из блоков. Удаляется все тоже по правилам по всем. НО полсе создания примерно 450 000 штук запросов(объектов типа запрос) размер ОП выделяемой программой увеличивается на 120 М получается что структура размером 300 байт не удаляется вопреки ожиданиям. После завершения программы размер свободной ОП восстанавливается.
V>Т.е. я понимаю что после вызова деструктора память не освобождаемтся.

А что BoundsChecker говорит?

Здравствуйте, ArtDenis, Вы писали:
AD>А что BoundsChecker говорит?

просто на Pascal кажется нет такого.
просто проблемма состоит в том что базовые классы моей модели написаны на Object Pascal

Здравствуйте, Leonid Troyanovsky, Вы писали:

LT> А что, собс-но, ты ищешь?

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

Здравствуйте, Аноним, Вы писали:

LT> А что, собс-но, ты ищешь?

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

Во-первых, непонятно как ты оцениваешь размер свободной памяти.
Если ты смотришь из Task Manager(NT-XP) — это не совсем то, чем кажется. (Если приложение с формой, то попробуй, например, свернуть и развернуть его).
Оценивать же свое приложение лучше с помощью Performarnce Monitor, для объекта Process (своего приложения).

Ну, а по существу — 450 тыс. объектов — если они все время создаются и
разрушаются — на мой взгляд — перебор. Лучше попытаться описывать _это_ не
объектами а записями, т.е. TMyQuery = record .. end;
Память же для такого массива не грех распределить самому, т.е.
VirtualAlloc. Тогда и за ее освобождение (VirtualFree) пенять придется
только на себя.
Если же нужно все это хозяйство хранить (на диске) то лучше сразу
смотреть в сторону CreateFileMapping — MapViewOfFile.

--
С уважением, LVT.

Здравствуйте, Leonid Troyanovsky, Вы писали:
LT> Во-первых, непонятно как ты оцениваешь размер свободной памяти.
LT> Если ты смотришь из Task Manager(NT-XP) — это не совсем то, чем кажется. (Если приложение с формой, то попробуй, например, свернуть и развернуть его).
LT> Оценивать же свое приложение лучше с помощью Performarnce Monitor, для объекта Process (своего приложения).

LT> Ну, а по существу — 450 тыс. объектов — если они все время создаются и
LT> разрушаются — на мой взгляд — перебор. Лучше попытаться описывать _это_ не
LT> объектами а записями, т.е. TMyQuery = record .. end;
LT> Память же для такого массива не грех распределить самому, т.е.
LT> VirtualAlloc. Тогда и за ее освобождение (VirtualFree) пенять придется
LT> только на себя.
LT> Если же нужно все это хозяйство хранить (на диске) то лучше сразу
LT> смотреть в сторону CreateFileMapping — MapViewOfFile.

Да на самао деле по таск менеджеру но только рост оперативки на столько силен что ни какие свертываения окон не помогают.

а 450 тысяч объектов за моджельное время около 2 часов, по машинному около минуты

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

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

Приветствую, vedmalex.

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

Ну, тогда NewInstance/FreeInstance тебе в руки.
По-крайней мере сам сможешь следить за своей памятью.
Правда, другие объекты, входящие в поля будут по-прежнему управляться дельфийским менеджером.

--
С уважением, LVT.

Здравствуйте, Leonid Troyanovsky, Вы писали:

LT> Ну, тогда NewInstance/FreeInstance тебе в руки.
LT> По-крайней мере сам сможешь следить за своей памятью.
LT> Правда, другие объекты, входящие в поля будут по-прежнему управляться дельфийским менеджером.

ОК.
Но я так же подумаю на счет размещения в записи,
по крайней мере можно создать объект который будет работать с запросами типа рекорд.

Спасибо за наметку

Здравствуйте, Leonid Troyanovsky, Вы писали:

LT> Правда, другие объекты, входящие в поля будут по-прежнему управляться дельфийским менеджером.
Ну, его тоже заменить не проблема. Можно посмотреть исходник ShareMem для примера.

Приветствую, Sinclair.

LT> Правда, другие объекты, входящие в поля будут по-прежнему управляться дельфийским менеджером.
> Ну, его тоже заменить не проблема. Можно посмотреть исходник ShareMem для примера.

Да, конечно. Правда, на практике с таким не сталкивался, т.к. мне сложно предложить нечто более эффективное, скажем, для строк или вариантов Скорее, я мог бы столкнуться с вариантом замены библиотечного менеджера на таковой из приложения, но и это, слава Богу, меня миновало.

--
С уважением, LVT.

Приветствую.

> Но я так же подумаю на счет размещения в записи,
> по крайней мере можно создать объект который будет работать с запросами типа рекорд.

Удобно размышлять над записями, как над объектами, разместив методы работы с ними в отдельном модуле.

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

--
С уважением, LVT.

Здравствуйте, Leonid Troyanovsky, Вы писали:

LT> Процедуры(глобальные) этого модуля принимают первым параметром указатель на обрабатываемую запись.
LT> Конечно, писать приходится немного больше, чем в случае объектов, но логика практически такая же.
LT> Также это облегчает создание истинно объектной оболочки (если она вдруг потребуется), путем написания объекта-прокси.

ОК.
Что то похожее я и собираюсь сделать.
Спасибо.

У меня та же проблема.
А как правильно удалять свой компонент? Я его создаю на форме, удаляю, а он всё висит и на все события реагирует. Создаю new, удаляю delete.

Здравствуйте, Prinzip, Вы писали:

P>У меня та же проблема.
P>А как правильно удалять свой компонент? Я его создаю на форме, удаляю, а он всё висит и на все события реагирует. Создаю new, удаляю delete.
Очень сранно. Никогда с подобным не сталкивался. По подробнее можно?