есть программа.
создает applet.

формы нет. больших объемов данных нет.
файл 90 кб.
в оперативке занимает 3-4 мб. откуда?
работает с десятком-другим коротких динамических массивов и битмапом размерами 200х50 точек. ну, с канвой конечно. да еще и stream для загрузки из файла.

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

или подобная вещь типична для дельфей вообще и не лечится?

а ведь в диспетчере задач висят процессы у который использование оперативки и 100 кб и 50кб.
я тоже так хочу!

^

ну, где-то так

> ну, где-то так

Лучше так, одной строкой -     SetProcessWorkingSetSize(GetCurrentProcess, DWORD(-1), DWORD(-1));

Но это все самообман. Приложение на КОЛ действительно "кушает" памяти гораздо больше чем аналогичное на чистом WinApi. Здесь нужно серьезно разбираться...

> я тоже так хочу!

с

> работает с десятком-другим коротких динамических массивов
> и битмапом размерами 200х50 точек. ну, с канвой конечно.
>  да еще и stream для загрузки из файла.

ты хочешь чтобы прога занимала 100 кб? Каким то образом, а?

ну, малость поизучал это дело

пустое консольное приложение где текста один единственный readln занимает 900 кб. без замены системных файлов.

добавление NewApplet доводит уровень оперативки до 1.6 мб.
тогда я подумал, может дело в ООП? и прикола ради решил переписать один модуль без использования ООП, то есть глобальный динамический массив и вложенные record и сравнил с тем же модулем, но на вложенных object.
результат получился одинаковым!
решил покосить на строки, ведь это же массивы и под них динамически выделяется память.
тогда заменил string на shortstring результат получился неоднозначным: shortstring в модуле без ООП добавил 400кб оперативки, а в модуле с ООП не дал разницы.
гм.

про SetProcessWorkingSetSize(GetCurrentProcess, DWORD(-1), DWORD(-1)); спасибо, посмотрю

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

А ты посмотри какие длл грузятся вместе с приложением. Например, такой код:
program tiny;
uses kol;
begin
 MsgOk('1');
end.
на винте занимает 14Кб, в памяти 44кб, далее список длл:
- ntdll.dll - 0.7Mb
- kernel32.dll - 1.0 Mb
- User32.dll - 0.6 Mb
- Gdi32.dll - 284 Kb
- Advapi32.dll - 0.7 Mb
- Rpcrt4.dll - 0.6 Mb
- Secur32.dll - 68 Kb
- Uxtheme.dll - 224 Kb
- Msvcrt.dll - 352 Kb
- Msctf.dll - 300 Kb
итого около 2Мб.

> итого около 2Мб.

Большинство dll во время старта программы будут уже загружены. Так что нам они ничем не мешают

кстати еще посмотрел в сторону выделения памяти под что-то командой компилятора {$M 0,0} (что-то такое) и прога не запустилась :) поигрался со значениям, но эффекта тоже не получил.

> а ведь в диспетчере задач висят процессы у который использование оперативки и 100 кб и 50кб.

Среди обычных программ там что-нибудь есть? Или только сервисы и ntvdm?

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

Создавай окно с hWndParent = HWND_MESSAGE, может, поможет сэкономить ресурсов.

> кстати еще посмотрел в сторону выделения памяти под что-то командой компилятора {$M 0,0}

Не издевайся над стеком. Все равно под него память только резервируется, а не выделяется, а если резерв закончится, Windows просто прибъет твою прогу без всяких сообщений.

А вообще lse [6] правильную мысль высказал.

Господа, вообще говоря, этот вопрос уже здесь обсуждался, и даже неоднократно.
Вкратце, объем памяти показываемый в диспетчере НЕ СООТВЕТСТВУЕТ реальной физической памяти, выделенной процессу.
Хотите, чтобы в диспетчере отображались меньшие цифры? Используйте
SetProcessWorkingSetSize

Что касается использования GetCurrentProcess, то на мой взгляд, сделать CloseHandle идеологически вернее. ИМХО. Все ж таки не на JAVA или C# пишем.
Не стоит расслабляться даже в мелочах.

> Vadim Petrov   [10]

А что разве
открывает какойто
?