Multiple .NET procesa la huella de memoria

Question

Estoy desarrollando un conjunto de aplicaciones que consiste en varias aplicaciones que el usuario puede ejecutar según sea necesario (pueden ejecutar todas al mismo tiempo, o solo varias ...).

Mi preocupación es en la huella de memoria física de cada proceso, como se muestra en el administrador de tareas.

Soy consciente de que Framework gestiona la memoria detrás de las cortinas en términos de que dedica partes de la memoria a ciertas cosas que no están directamente relacionadas con mi aplicación.

La pregunta.¿.NET Framework tiene alguna manera de minimizar la huella de memoria de los procesos que ejecuta cuando hay varios procesos ejecutándose al mismo tiempo? (Noobish guess ahead) Al igual que si System.dll ya está cargado por un proceso, ¿el marco lo carga para cada proceso, o tiene alguna forma de compartirlo entre los procesos?

De ninguna manera me esfuerzo por escribir aplicaciones tan pequeñas (basadas en los recursos) como sea posible (si lo fuera, probablemente no usaría .NET Framework en primer lugar), pero si hay algo que pueda hacer algo sobre el uso excesivo de recursos, me gustaría saber al respecto.

Answer 1

Cuando se utiliza NGEN para pre-JIT ensambles, se hace de tal manera que si el mismo ensamblado se carga en procesos múltiples, el código ejecutable puede compartirse entre ellos (de lo contrario, cada proceso debe tener una copia de ambos el IL original y el código compilado JIT).

La mayoría (todos?) De las bibliotecas de bases en el marco NGEN se compilan cuando el marco está instalado en parte por esta razón (también para disminuir el tiempo de inicio de aplicaciones .NET)

Rico es el experto indiscutible en esto: http://blogs.msdn.com/b/ricom/archive/2004/10/18/244242.aspx

Además muchas de esas páginas se pueden compartir a través de procesos por lo que nos gusta animar a poner el código compartible en imágenes ngen'd - código compilados JIT no puede ser compartida.

Answer 2

El sistema operativo Windows tiene una forma de minimizar la huella de memoria de múltiples procesos. Se conoce como paginación.

Answer 3

No espero que el .NET Framework haga algo como esto, y me gusta de esa manera. La razón es que no confiaría en el framework .net para hacer la gestión del estado para cada proceso. Quiero decir, si un DLL es compartido por dos procesos, el contexto y el estado pueden ser diferentes para cada caso, y podríamos necesitar instancias diferentes.

Por ejemplo, tomemos winword.exe - si dos procesos han abierto dos documentos diferentes, habría dos instancias de winword ejecutándose en la memoria. No me gustaría que .net f/w se entrometa con eso, especialmente cuando se trata del mundo COM.

Sin embargo, dejaría que la DLL sea tan inteligente, se comporte como singleton si no quiere que varias instancias se ejecuten simultáneamente.

Answer 4

El CLR y el compilador JIT son DLL comunes de Windows. Solo una instancia del código se carga en la memoria virtual, sus páginas son compartidas por cualquier proceso .NET. Sus datos son privados para cada proceso. Lo mismo es cierto para cualquiera de los ensamblados en el marco .NET, fueron ngen-ed cuando se instaló .NET en la máquina. Probablemente no sea cierto para su propio código, el código compilado JIT no se puede compartir.Rara vez hay un punto, ya que a menudo no ejecuta el mismo programa más de una vez.

Al igual que .NET administra automáticamente la memoria, también lo hace Windows. Casi lo único que puede hacer es obligar a su programa a cambiarse al disco a menudo configurando Process.MaxWorkingSet. Esto no es sabio Minimizar la ventana principal de su aplicación también lo hace.

Como regla general, no puede tomar decisiones correctas en su propio programa y adivinar correctamente si es conveniente o no recortar el conjunto de trabajo. No sabe qué otros procesos se están ejecutando y cuánta RAM necesitan. Windows sí.