¿Alguna vez ha usado ngen.exe?

Question

¿Alguien ha usado alguna vez ngen? ¿Dónde? ¿por qué? ¿Hubo alguna mejora en el rendimiento? ¿Cuándo y dónde tiene sentido usarlo?

Answer 1

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 dependemos de ensambles 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.

Answer 2

ngen es principalmente conocido por mejorar el tiempo de arranque (al eliminar la compilación 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 durante la instalación.

Answer 3

No lo uso día a día, pero lo utilizan las herramientas que desean 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 gran 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 que sea un trabajo innecesario, pero no se puede saber 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).

Answer 4

lo he usado pero solo con fines de investigación. Úselo ÚNICAMENTE si está seguro de la arquitectura de CPU de su entorno de despliegue (no cambiará)

pero déjeme decirle que la compilación JIT no es tan mala y si tiene implementaciones en múltiples entornos de CPU (por ejemplo, un cliente de Windows aplicación que se actualiza a menudo) LUEGO NO UTILICE 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 claro ganador en estos casos, ya que optimiza el código sobre la marcha basándose en la arquitectura de la CPU que se está ejecutando. (por ejemplo, puede detectar si hay más de 1 CPU)

y clr está mejorando con cada versión, por lo tanto, en corto plazo con JIT a menos que esté absolutamente seguro de su entorno de despliegue, incluso entonces su rendimiento aumentará difícilmente justificar el uso de ngen.exe (probablemente ganancias serían de unos pocos cientos de ms) - en mi humilde opinión - no vale la pena el esfuerzo

también puedes ver este enlace agradable real en este tema - JIT Compilation and Performance - To NGen or Not to NGen?

Answer 5

Ngen reduce principalmente el tiempo de inicio de la aplicación .NET y el conjunto de trabajo de la aplicación. Pero es tener algunas desventajas (de CLR a través de C# de Jeffrey Richter):

n Protección de la Propiedad Intelectual

archivos NGen'd puede perder la sincronización

inferior rendimiento en tiempo de carga (Rebase/Encuadernación)

inferior Ejecución de fechas de

Debido a todos los problemas que acabamos de mencionar, se debe tener mucho cuidado cuando se considera 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. En el Además, para la mayoría de las aplicaciones de servidor, solo se requiere una instancia del código, por lo que no hay beneficio de conjunto de trabajo .

Para aplicaciones de 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 conjunto. Incluso en un caso en cuyo ensamblaje no es utilizado por múltiples aplicaciones, NGen'ing un conjunto podría mejorar el conjunto de trabajo . Además, si NGen.exe se utiliza para todos los ensamblados de una aplicación cliente, CLR no necesitará cargar el compilador JIT en absoluto, reduciendo aún más el conjunto de trabajo. Por supuesto, si solo un 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á.

Answer 6

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 mostraba cuando perfilaba la aplicación, pero después de buscar en JIT compilando y NGEN, pensé que no valía la pena. La sobrecarga en el tiempo de instalación, con la administración , mi mayor preocupación, me hizo ignorar los signos y centrarme en , agregando más funcionalidad a la aplicación. Cuando cambiamos la arquitectura a "Cualquier CPU" que se ejecuta en máquinas de 64 bits empeoramos: Experimentamos un bloqueo en nuestra aplicación de hasta 10 segundos en una sola declaración , con el perfilador mostrando solo sobrecarga JIT en el área problemática . NGEN resolvió el problema: la declaración pasó de 10 segundos a 1 milisegundo. Esta afirmación no formaba parte del procedimiento de inicio , por lo que estaba ansioso por descubrir qué podría hacer NGEN con la aplicación al momento del inicio. Pasó de 8 segundos a 3.5 segundos.

Conclusión: ¡Realmente recomiendo probar NGEN en su aplicación!

Answer 7

Como una adición al comentario de Mehrdad Afshari sobre la 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 potencialmente un enorme efecto (en nuestro caso, gigabytes y minutos).

Más información aquí: XmlSerializer startup HUGE performance loss on 64bit systems ver la respuesta de Nick Martyshchenko especialmente.

Answer 8

Sí, lo probé con un pequeño exe de uso intensivo de la 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 me dieron los siguientes tiempos reproducible +/- 0,1 s: 33.9s 35.3s sin , con