Несколько. NET процессов памяти

Question

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

Меня беспокоит объем физической памяти каждого процесса, как показано в диспетчере задач.

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

Вопрос. Есть ли у .NET Framework какой-либо способ минимизировать объем памяти процессов, которые он выполняет, когда одновременно запущено несколько процессов? ( Noobish догадка вперед ) Например, если System.dll уже загружен одним процессом, загружает ли фреймворк его для каждого процесса или у него есть какой-то способ разделения его между процессами?

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

Answer 1

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

Большинство (все?) Базовых библиотек в инфраструктуре скомпилированы NGEN, если среда частично установлена ​​по этой причине (также для уменьшения начального времени запуска приложений .NET)

Рико является бесспорным экспертом в этом: http://blogs.msdn.com/b/ricom/archive/2004/10/18/244242.aspx

Кроме того, многие из этих страниц могут быть общими для всех процессов, поэтому мы хотели бы поощрять размещение разделяемого кода в изображениях ngen - объединенный код не может использоваться совместно.

Answer 2

CLR и JIT-компилятор - это обычные библиотеки Windows DLL. Только один экземпляр кода загружается в виртуальную память, его страницы совместно используются любым процессом .NET. Их данные являются частными для каждого процесса. То же самое верно для любой сборки в .NET Framework, они были созданы при установке .NET на машину. Вероятно, это неверно для вашего собственного кода, JIT-скомпилированный код не является разделяемым. В этом нет особого смысла, поскольку вы не часто запускаете одну и ту же программу более одного раза.

Как .NET автоматически управляет памятью, так и Windows. Почти единственное, что вы можете сделать, это заставить вашу программу часто выгружаться на диск, устанавливая Process.MaxWorkingSet. Это не мудро. Свернуть главное окно вашего приложения тоже можно.

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

Answer 3

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

Answer 4

Я не ожидаю, что .net framework сделает что-то подобное, и мне нравится именно так. Причина в том, что я бы не стал доверять инфраструктуре .net управление состоянием для каждого процесса. Я имею в виду, если DLL совместно используется двумя процессами, контекст и состояние могут быть разными для каждого случая, и нам могут потребоваться разные экземпляры.

Например, давайте возьмем winword.exe - если два процесса открыли два разных документа, в памяти было бы два экземпляра winword. Я бы не хотел, чтобы .net f / w вмешивался в это, особенно когда речь идет о мире COM.

Тем не менее, я бы хотел, чтобы сама библиотека DLL была настолько умной, вела бы себя как одиночка, если вы не хотите, чтобы несколько экземпляров работали одновременно.