Собственно вопрос: Как задать максимальный размер выделяемой под приложение памяти?
Помню, че-то такое было, но даже приблизительно не помню че. Помогите, плиз   .

А разве дотнетовское приложение не кушает всю свободную память ? Вроде, для Win32-приложений то же самое.

mr.DUDA, вот и я того же мнения. 
В классе Сборщика мусора нет свойства отвечающего за предел памяти   
Если бы было, то было бы именно там   

Не, неправильный вопрос. Не максимальный, а первоначальный. Насколько я знаю, винда при старте процесса выделяет для него сколько-то памяти с резервом. Если для процесса этой памяти недостаточно, выделяется дополнительно еще сколько-то памяти с резервом. И так далее. Так вот эти моменты выделения дополнительной памяти довольно длительные   . Если при старте программы задать первоначльный размер памяти с очень большим резервом, то, по идее, она должна работать побыстрее. 
Так вот как задать размер первоначально выделяемой памяти?

З.Ы. Где-то это точно было.

З.З.Ы. Возможно даже и не в .NET.   

SQL SERVER умеет такое, значит возможно. но как? вот это вопрос.

А это ответ -- VirtualAlloc
Только это из WinAPI и в .NET от него никакой пользы не будет.
Я вообще не очень понимаю, как автоматическая сборка мусора может сочетаться с ручным резервированием памяти?

Это сообщение отредактировал(а) Дрон - 5.10.2006, 13:03

Это как для класса List<T> есть понятие capacity = начальная емкость. 
Изначально она вроде 4, а потом возрастает в геометрической прогрессии (знаменатель 2) по мере надобности. Так вот если ты 100% уверен, что у тебя будет 10-20-100 элементов, то можно ставить емкость в это значение (или чуть больше). Это сэкономит часть ресурсов при перевыделении памяти   

Это сообщение отредактировал(а) ivashkanet - 5.10.2006, 13:18

Вот именно для этих целей мне и нужно ограничивать память. Потому что получается нифика она не автоматическая. Как я понял, почитав MSDN, сборщик мусора начинает собирать мусор, когда не хватает памяти для создания нового объекта. 
А в силу 

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

Я не понял, что тебе надо? Ограничить сверху? Или задать начальную "емкость" памяти?

P.S. System.GC.Collect() тебе в руки   Да и вообще весь класс System.GC

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

Небольшое расследование показало наличие метода GC.AddMemoryPressure, но он действует только для unmanaged-памяти. Можно попробовать создать свой поток, который будет с периодичностью N.N секунд проверять размер выделенной памяти и по превышению - вызывать GC.Collect

 
  

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

и

если ручками не управлять этим самым GC. 
А насчет первоначальной памяти было несколько советов. 

Поискал в MSDN. capacity - есть у многих классов. Но почему то нет у Application.
Буду пробовать. Спасибо за помощь.

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

я бы не стал этой ерундой заниматься. откуда ты знаешь, сколько тебе нужно памяти пусть и с запасом? дошли уже до ручного управления GC! если все такие умные, что ж вы сам .net раньше не написали.

  

Простите, простите я ничего плохого про разработчиков .NET Framework SDK не говорил, и ничего не говорил про свои и их умственные способности. 
А про ручное управление GC это не так уж страшно, а для unmanaged-ресурсов просто необходимо показать этому GC, как их собирать.



http://msdn.microsoft.com/library/rus/defa...ymanagement.asp

Naum, ты не путай "ручное управление GC" с необходимостью очищать unmanaged ресуры.
Это совершенно разные вещи. 
Первое это влезание в логику работы механизма очистки, а второе это "объяснение" сборщику мусора как правильно работать с вещами, с которыми работать он изначально не умеет  

Хорошо, это я понял. Но зачем тогда класс GC, если управлять сборщиком ручками это плохо?

Чтобы была возможность (в исключительных случаях) произвести сборку вручную.

Например инициализация приложения требует очень больших ресурсов, но проводится она всего лишь раз в день (например). После инициализации эти ресурсы не нужны. Можно, конечно, оставить эти ресурсы до сборки мусора, но ты не хочешь, чтобы твой "трэй монитор" занимал 200М, не нужной ему сейчас, памяти. Вот ты и очищаешь ее.

Т.е. главное правило --- не злоупотребляй   

А этот случай

можно считать исключительным?

Добавлено @ 10:42 
Имеется ввиду не сервис, а Windows Forms или консольное приложение.

При отсутствии утечек памяти, приложение не будет есть больше определённого предела.

Вот именно это я и хотел узнать - больше определенного чем или кем предела оно не будет есть?

Зависит от того, сколько объектов создаёшь и как часто.

И еще интересно, почему не будет есть? Получаица, сборщик мусора собирает мусор не только в те моменты, когда для новых объектов уже не хватает памяти?

А я нашел кое-что интересное от ИвашкиНет..   . Размер не главное. Главное, что из написанного в этом топике ясно, что сборка мусора начинается не в то время, когда памяти уже не хватает совсем, а в то время, когда превышен какой-то барьер.
Хоть ответ и не в этом топике, все равно ИвашкиНет +1.

Naum, так то ж не мне 
Я просто к тому посту успел прочитать статью по ссылку Void-а. Вот и ответил.
P.S. Ссылка на статью назодится в том же топике   

Вспомнил. ИМХО, это не то, что мне надо, но просто так, если кому инетересно.

Naum,
Для управления рабочем множеством используется API функция SetProcessWorkingSetSize(находится в библиотеке kernel32), которая принимает хэндл процесса, минимальный и максимальный рамер рабочего множества.
Если же в качестве минимального и максимального размера передать -1, то рабочее множетсво минимизиируется до фактического размера выделенной памяти.
Не думаю, что стоит вызывать эту функцию для увеличения рабочего множества т.к. среда это делает сама с большой охотой и в основном к этой функции прибегают для уменьшения рабочего множетсва.

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