Совместное использование DLL между процессами - виртуальная память, кажется, не выигрывает

Question

Мое намерение состоит в том, чтобы делить dll между моими приложениями, так что если, например, у меня есть 2 приложения, которые загружают dll 20 МБ, чем вместо одного процесса, использующего память 200 МБ, а другого - тоже 200 МБ, одно из них получит выгоду от совместного использования ииспользуйте только 180 МБ памяти.Моя проблема с определением памяти, пожалуйста, продолжайте читать.

Я создал 2 приложения .net c #, которые ссылаются и запускают код из большой библиотеки DLL (20 МБ), которая находится в GAC.С .NET Memory Profiler я мог видеть, что фактически фактическая физическая память, которая использовалась вторым процессом, была значительно ниже той, которая была запущена первой (хотя они идентичны), и что dll была расположена под общей памятью первогопроцесс.Тем не менее, при проверке счетчиков памяти с помощью perfmon я увидел, что виртуальная память обоих приложений увеличивается (по сравнению с размером DLL) на тот же размер, который они увеличивают при запуске каждого из них по отдельности.

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

Редактировать: Спасибо за ответы.Основываясь на ответах, я хочу подчеркнуть, что я понимаю, как полезно делиться DLL в памяти, чтобы сохранить физическую память.Более точный вопрос, который я должен задать: есть ли какая-то польза от приложений (не от системы) от способа, которым библиотеки DLL распределяются между приложениями в .net?Я спрашиваю об этом потому, что меня волнует количество виртуальной памяти, которую используют мои приложения (всего).

Answer 1

RAM имеет значение.Виртуальная память ничего не стоит, она виртуальная.Несколько процессов, использующих одну и ту же оперативную память, - это большое делоЛюбой процесс Windows имеет зависимость от kernel32.dll.Но есть только одна копия его кода в оперативной памяти.

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

Answer 2

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

Я не уверен, как вы пришли к такому выводу. Система имеет ограниченный объем физической памяти, а не виртуальной памяти, поэтому сохранение физической памяти - это то, что эффективно имеет значение в долгосрочной перспективе.

Answer 3

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

В Windows библиотеки DLL имеют «предпочтительный адрес загрузки», встроенный в их образ.Если это конфликтует с адресом загрузки любых других библиотек DLL в том же процессе, то загрузчик должен «перебазировать» библиотеку DLL, что в основном означает прохождение и исправление абсолютных ссылок внутри библиотеки DLL.На этом этапе то, что было загружено, больше не совпадает с тем, что было получено с диска, и (что крайне важно) не совпадает с тем, что было загружено в адресное пространство любых других процессов, что означает, что оно не может быть разделено между процессами.

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

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

Вы можете установить предпочтительный адрес загрузки во время сборки или использовать инструмент SDK, называемый rebase post-build.Итак, если вы создаете несколько библиотек DLL, убедитесь, что их предпочтительные адреса загрузки не конфликтуют.Даже если вы создаете только одну DLL, вы должны убедиться, что она не конфликтует с другими, от которых зависит ваше приложение.

Answer 4

Вы, кажется, не думаете об этом правильно.Пространство процесса приложения - это виртуальная память.Чтобы код работал, он должен быть отображен в пространство процессов приложения.В противном случае, как он будет выполнять код, который он фактически не может видеть?

Физическая память распределяется, но ЦП должен иметь возможность видеть виртуальную память для ее выполнения.

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

Answer 5

Насколько я понимаю, совместное использование через GAC предназначено для экономии места на жестком диске, а не памяти. Каждое приложение, которое вызывает DLL из GAC, получит свою собственную копию DLL в памяти, как сказал ghimireniraj.