Pregunta

Fondo:En mi empresa estamos desarrollando un montón de aplicaciones que utilizan los mismos archivos DLL centrales.Estos DLL utilizan el contenedor IoC de Spring.net para conectar las cosas (cableado automático).Todas las aplicaciones utilizan el mismo archivo de configuración de Spring, y este archivo de configuración apunta a muchas clases en muchos archivos DLL diferentes.Pero no todas las aplicaciones necesitan la funcionalidad de cada dll.Pero debido a la forma en que funcionan los contenedores IoC, todos los dll se cargan para que Spring.net examine los tipos y verifique qué interfaces implementan, etc.

Pregunta central:Entiendo que es mejor simplemente cargar los archivos DLL que realmente usas.Pero, ¿es realmente malo para el uso de la memoria simplemente cargar una DLL administrada?¿O es primero, cuando estás usando clases en el dll y están obteniendo JIT que se usa la mayor cantidad de memoria?

¿Fue útil?

Solución

Si nunca se utiliza nada del código del ensamblado, eventualmente las páginas de ese ensamblado se moverán de la memoria al archivo de página en favor de las páginas utilizadas activamente.En cuyo caso, es probable que el efecto general a largo plazo sea menor.Sin embargo, habrá un efecto negativo en el tiempo de inicio.

Otros consejos

No creo que sea tan malo.El único problema es que debido a los grandes metadatos y la cantidad de memoria que ocupa su aplicación, es más posible que algunas partes de la aplicación que están en uso estén ubicadas en diferentes páginas de memoria, lo que puede causar algunas pérdidas de rendimiento, pero es un segmento muy bajo de la aplicación donde Este tipo de cosas son críticas.

Realmente malo es un término difícil de cuantificar, supongo que depende de la escala de las cosas, en general diría que si puedes evitar cargar cosas que no necesitas, entonces deberías hacerlo.Pero, por supuesto, si estás usando la reflexión para determinar si poder úsalo, primero tienes que cargarlo... el problema del huevo y la gallina.

Sin embargo, hay algo que debe tener en cuenta: una vez que carga un ensamblado en un dominio de aplicación, no puede descargarlo de ese dominio de aplicación; sin embargo, es posible crear dominios de aplicación dinámicamente, cargar ensamblados en él y descargar todo el dominio de la aplicación cuando esté hecho.

por supuesto, cargar archivos DLL sin usarlos provoca un tiempo de inicio más lento debido a la lectura del ensamblaje del disco y a las comprobaciones de evidencia/seguridad.Pero si lo que le preocupa es la memoria, al menos puede estar seguro de que no desperdiciará más memoria que el tamaño de sus ensamblajes si realmente no utiliza ningún tipo dentro.Por supuesto, si esos tipos se especifican en la configuración de Spring, al menos esos tipos se cargan en la memoria y se ejecutará su inicializador estático (si lo hay).En casos excepcionales, esto podría ser un problema.El CLR realiza JITing por método, por lo que los métodos que no utilice no desperdiciarán CPU + memoria.

En cualquier caso, puede dividir sus archivos de configuración en particiones, p.colocando todas las definiciones de objetos del módulo A en el archivo moduleA.config, todas las definiciones del módulo B en el archivo moduleB.config y especificando solo aquellos módulos para su aplicación particular que realmente sean necesarios.

hth, Erich

PD.:También me gustaría sugerirle que publique preguntas relevantes sobre Spring para .NET en nuestro foros comunitarios - Es más probable que obtenga respuestas a sus preguntas allí.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top