c# - que - ¿Alguna vez ha usado ngen.exe?
net runtime optimization service solucion (8)
¿Alguien ha usado alguna vez ngen? ¿Dónde? ¿por qué? ¿Hubo alguna mejora en el rendimiento? ¿Cuándo y dónde tiene sentido usarlo?
Como una adición al comentario de Mehrdad Afshari sobre compilación de JIT. Si se serializa una clase con muchas propiedades a través de XmlSerializer y en un sistema de 64 bits, un combo SGEN, NGEN tiene un efecto potencialmente enorme (en nuestro caso, gigabytes y minutos).
Más información aquí: Inicio de XmlSerializer ENORME pérdida de rendimiento en sistemas de 64 bits, vea la respuesta de Nick Martyshchenko especialmente.
Lo he usado pero solo para fines de investigación. Úselo ÚNICAMENTE si está seguro de la arquitectura de la CPU de su entorno de despliegue (no cambiará)
pero déjame decirte que la compilación de JIT no es tan mala y si tienes implementaciones en múltiples entornos de CPU (por ejemplo, una aplicación de cliente de Windows que se actualiza a menudo) LUEGO NO UTILICES NGEN. Eso es porque un caché ngen válido depende de muchos atributos. si uno de estos falla, su ensamblaje vuelve a funcionar de nuevo
JIT es un ganador claro en tales casos, ya que optimiza el código sobre la marcha basado en la arquitectura de la CPU que se ejecuta. (por ejemplo, puede detectar si hay más de 1 CPU)
y clr está mejorando con cada versión, por lo que en corto plazo con JIT a menos que esté completamente seguro de su entorno de despliegue, incluso entonces su aumento de rendimiento difícilmente justificaría usar ngen.exe (probablemente las ganancias estarían en pocos cientos de ms) - imho - no vale la pena el esfuerzo
también verifique este enlace realmente bueno sobre este tema - Compilación JIT y rendimiento - ¿A NGen o No a NGen?
Ngen reduce principalmente el tiempo de inicio de la aplicación .NET y el conjunto de trabajo de la aplicación. Pero tiene algunas desventajas (de CLR Via C # de Jeffrey Richter):
Sin protección de propiedad intelectual
Los archivos NGen no se pueden sincronizar
Rendimiento de tiempo de carga inferior (Rebasing / Binding)
Inferior Execution-Time Performance
Debido a todos los problemas que acabamos de mencionar, debe tener mucho cuidado al considerar el uso de NGen.exe. Para las aplicaciones del lado del servidor, NGen.exe tiene poco o ningún sentido porque solo la primera solicitud del cliente experimenta un golpe de rendimiento; las futuras solicitudes de clientes se ejecutan a alta velocidad. Además, para la mayoría de las aplicaciones de servidor, solo se requiere una instancia del código, por lo que no existe un beneficio de conjunto de trabajo.
Para las aplicaciones cliente, NGen.exe podría tener sentido para mejorar el tiempo de inicio o para reducir el conjunto de trabajo si varias aplicaciones usan simultáneamente un ensamblaje. Incluso en un caso en el que un ensamblaje no es utilizado por múltiples aplicaciones, NGen''ing un conjunto podría mejorar el conjunto de trabajo. Además, si se utiliza NGen.exe para todos los ensamblados de una aplicación cliente, no será necesario que el CLR cargue el compilador JIT, lo que reducirá aún más el conjunto de trabajo. Por supuesto, si un solo ensamblaje no está NGen''d o si no se puede usar el archivo NGen''d de un ensamblaje, el compilador JIT se cargará y el conjunto de trabajo de la aplicación aumentará.
No lo uso día a día, pero lo usan las herramientas que quieren aumentar el rendimiento; por ejemplo, Paint.NET utiliza NGEN durante el instalador (o tal vez el primer uso). Es posible (aunque no estoy seguro) que algunas de las herramientas de MS también lo hagan.
Básicamente, NGEN realiza la mayor parte del JIT para un conjunto en la parte delantera, por lo que hay muy poco retraso en un arranque en frío. Por supuesto, en el uso más típico, no se llega al 100% del código, por lo que de alguna manera esto hace un montón de trabajo innecesario , pero no puede decirlo con anticipación.
La desventaja, IMO, es que necesita usar el GAC para usar NGEN; Intento evitar el GAC tanto como sea posible, de modo que pueda usar robocopy-deployment (para servidores) y ClickOnce (para clientes).
Sí, he visto mejoras en el rendimiento. Mis mediciones indicaron que sí mejoró el rendimiento de inicio si también pongo mis ensamblajes en el GAC ya que mis ensamblajes tienen un nombre fuerte. Si sus ensamblajes tienen un nombre fuerte, NGen no hará ninguna diferencia sin usar el GAC. La razón de esto es que si tiene ensamblados con nombres fuertes que no están en el GAC, el tiempo de ejecución de .NET valida que su ensamblado con nombre fuerte no haya sido alterado cargando todo el ensamblaje administrado desde el disco para que pueda validar su elusión uno de los principales beneficios de NGen.
Esta no era una opción muy buena para mi aplicación ya que confiamos en ensamblajes comunes de nuestra compañía (que también tienen un nombre fuerte). Los ensambles comunes son utilizados por muchos productos que usan muchas versiones diferentes, ponerlos en el GAC significó que si una de nuestras aplicaciones no dijera "usar versión específica" de uno de los ensamblajes comunes cargaría la versión GAC sin importar qué la versión estaba en su directorio de ejecución. Decidimos que los beneficios de NGen no justificaban los riesgos.
Sí, lo probé con un pequeño y único administrador intensivo de CPU y con ngen fue un poco más lento.
Instalé y desinstalé la imagen ngen varias veces y ejecuté un punto de referencia.
Siempre obtuve los siguientes tiempos reproducibles +/- 0.1s: 33.9s sin, 35.3s con
Sí. Usado en una aplicación WPF para acelerar el tiempo de inicio. El tiempo de inicio pasó de 9 segundos a 5 segundos. Lea sobre esto en mi blog :
Recientemente descubrí lo genial que puede ser NGEN para el rendimiento. La aplicación en la que actualmente trabajo tiene una capa de acceso a datos (DAL) que se genera. El esquema de la base de datos es bastante grande, y también generamos algunos de los datos (lista de valores) directamente en el DAL. Resultado: muchas clases con muchos campos y muchos métodos. La sobrecarga de JIT a menudo aparecía cuando se perfilaba la aplicación, pero después de una búsqueda en compilación de JIT y NGEN, pensé que no valía la pena. La sobrecarga en el tiempo de instalación, con la administración como mi mayor preocupación, me hizo ignorar los signos y centrarme en agregar más funcionalidad a la aplicación. Cuando cambiamos la arquitectura a "Cualquier CPU" que se ejecutaba en máquinas de 64 bits, las cosas empeoraron: experimentamos un bloqueo en nuestra aplicación de hasta 10 segundos en un único enunciado, con el generador de perfiles mostrando solo la sobrecarga JIT en el área del problema. NGEN resolvió el problema: la declaración pasó de 10 segundos a 1 milisegundo. Esta declaración no formaba parte del procedimiento de inicio, por lo que estaba ansioso por descubrir qué podría hacer NGEN en toda la aplicación para el tiempo de inicio. Pasó de 8 segundos a 3.5 segundos.
Conclusión: ¡Realmente recomiendo probar NGEN en su aplicación!
ngen es principalmente conocido por mejorar el tiempo de arranque (al eliminar la compilación de JIT). Puede mejorar (reduciendo el tiempo de JIT) o disminuir el rendimiento general de la aplicación (ya que algunas optimizaciones de JIT no estarán disponibles).
.NET Framework usa ngen para muchos ensambles en la instalación.