Как уменьшить размер памяти, который отводится для стандартной Win32 проги? А то делаешь прогу размером 1Кб, а в памяти она занимает несколько мегов. Сильно не пинайте.
Вообшето изменить значения в PE заголовке(Размер секций), если речь про вирт память. На чём пишешь и чем компилешь?
Если посчитать юзер виртуальную память процесса , то так и получится пару мегов (w2k), а что там такс манагер показывает х.з. Код (Text): <font color="green]Address Size (Decimal) Owner Section Contains Type Access</font><!--color--> 00010000 00001000 (4096.) 00010000 (itself) Priv 00021004 RW 00020000 00001000 (4096.) 00020000 (itself) Priv 00021004 RW 0006D000 00001000 (4096.) 00030000 Priv 00021104 RW 0006E000 00002000 (8192.) 00030000 stack Priv 00021104 RW 00070000 00003000 (12288.) 00070000 (itself) Priv 00021004 RW 00080000 00003000 (12288.) 00080000 (itself) Map 00041004 RW <font color="red]00090000 00016000 (90112.) 00090000 (itself) Map 00041002 R 000B0000 0002F000 (192512.) 000B0000 (itself) Map 00041002 R 000E0000 00041000 (266240.) 000E0000 (itself) Map 00041002 R 00130000 00004000 (16384.) 00130000 (itself) Map 00041002 R</font><!--color--> 00400000 00001000 (4096.) test 00400000 (itself) PE header Imag 01001002 R 00401000 00001000 (4096.) test 00400000 .flat code,imports Imag 01001002 R 77F80000 00001000 (4096.) ntdll 77F80000 (itself) PE header Imag 01001002 R 77F81000 00045000 (282624.) ntdll 77F80000 .text code,exports Imag 01001002 R 77FC6000 00005000 (20480.) ntdll 77F80000 ECODE code Imag 01001002 R 77FCB000 00004000 (16384.) ntdll 77F80000 PAGE code Imag 01001002 R 77FCF000 00003000 (12288.) ntdll 77F80000 .data data Imag 01001002 R 77FD2000 00028000 (163840.) ntdll 77F80000 .rsrc resources Imag 01001002 R 77FFA000 00002000 (8192.) ntdll 77F80000 .reloc relocations Imag 01001002 R 793A0000 00001000 (4096.) kernel32 793A0000 (itself) PE header Imag 01001002 R 793A1000 0005F000 (389120.) kernel32 793A0000 .text code,imports Imag 01001002 R 79400000 00004000 (16384.) kernel32 793A0000 .data data Imag 01001002 R 79404000 00052000 (335872.) kernel32 793A0000 .rsrc resources Imag 01001002 R 79456000 00004000 (16384.) kernel32 793A0000 .reloc relocations Imag 01001002 R <font color="red]7F6F0000 00007000 (28672.) 7F6F0000 (itself) Map 00041020 R E 7FFB0000 00024000 (147456.) 7FFB0000 (itself) Map 00041002 R</font><!--color--> 7FFDE000 00001000 (4096.) 7FFDE000 (itself) data block Priv 00021040 RWE 7FFDF000 00001000 (4096.) 7FFDF000 (itself) Priv 00021040 RWE <font color="red]7FFE0000 00001000 (4096.) 7FFE0000 (itself) Priv 00021002 R</font><!--color--> Чем больше библиотек юзает прога, тем больше память Кста, красным выделил страницы, доступны только для чтения из юзера
Вообще-то меня интересовали возможности опций компилятора по уменьшению используемой памяти. Но, судя по данным от bogrus, получается, что любая прога юзает хотя бы kernel32.dll. А с ней и ntdll.dll. И тут уже никакие опции компилятора не помогут. Прога всё-равно будет жрать память как дура, пытаясь разместить эти библиотеки.
Это виртуальная память, ее можно жрать. А физически системные DLL грузятся в единственном экземпляре, и в каждом процессе живут не они сами, а их дУхи Запусти тыщу килобайтно-мегабайтного размера, и сам все увидишь: формально винда должна подохнуть в жутких мучениях, исчерпав и память, и своп. Но не подохнет!
Код подгружаемых DLL не хранится в свопе (если не изменен), а грузится страницами прямо из файла на диске. А прога занимает как минимум 3 страницы: заголовок, код и стек. те 12 кило.
Больше занимает, до того как код проги получит управление, ntdll и kernel уже работают со стеком, PEB'ом, хипом и другими страницами, т.ч. они уже в ОЗУ, а те к которым обращений не было, то могут и не присутствовать. Другое дело, что менеджер памяти, если её мало и другим задачам не хватает, то может сбросить страницы, а переключение контекстов происходит около 300 раз в секунду, Page Fault'ы можно тоже посмотреть у себя CPUMon'ом, иногда 0, иногда 3 страницы за секунду. Гиблое дело замерять точно, может Get\SetProcessWorkingSetSize кому поможет (The "working set" of a process is the set of memory pages currently visible to the process in physical RAM memory)
Я спросил по поводу того, что делаешь какую-нибудь прогу типа Hello world, а она занимает в памяти 1,5 мегов, хотя на диске лишь 1 кб. И тут же висят процессы размером сотни, а то и десятки килов всего. Обидно.
Так я и говорю: расслабься. Твоя программа реально в памяти занимает очень мало килобайт, а Таск Манагер - дуру гонит, складывая объем твоей проги с объемом всех загруженых в ее адресное пространство DLL. Реально системные DLL существуют в физической памяти в единственном экземпляре. Запусти две незапакованные однокилобайтные программы параллельно и сам увидишь, как изменится объем занятой памяти.
В NT ? Что-то меня грызут сомнения ... Ведь системные длл-ки имеют свои данные и не факт, что они одинаковы для каждого процесса, значит, по крайней мере страницы .data существуют во многих экземплярах. А с другой стороны системные длл грузятся всегда по одному виртуальному адресу (возможно так легче мапить их на физические?), но этому можно найти объяснение (ускоряется загрузка и их "связывание")
SolidCode > Это из-за того, что прога GUI. Виндос выделяет тучу памяти под окно для MessageBox, очередь сообщений и т.п.
harley Процесс ест сколько и когда ему надо, чем больше библиотек тем больше им необходимо памяти, тоже можно сказать о буферах, с одним KERNEL32.dll можно насоздавать тучу массивов и постоянно работать с ними (страницами памяти), физ. память по таскманагеру будет расти пока весь RAM не займет, а тогда начнется нехватка и когда ты обратишся к странице виртуальной памяти (которой нет в физической), тогда менеджер выберет давно используемую? страницу, если была изменена - скинет в своп, если нет, то сразу перенесет на её место новую (а ту уже достанет откуда брал, если конечно она ещё понадобится), кажется так ... а представь когда работает множество процессов и очень мало памяти, а если они ещё с окнами на экране, между которыми лихорадочно переключаешься, то эти страницы летают как угорелые и при переходе на очередное окно наблюдаем жужжание винта, медленную перерисовку окон и заторможеное реагирование на кнопки, т.ч. у других таскменеджер может показывать совсем не так как у тебя
