Avez-vous déjà utilisé ngen.exe ?

Question

Quelqu'un ici a-t-il déjà utilisé ngen ? Où ? Pourquoi ? Y a-t-il eu une amélioration des performances ? Quand et où est-il judicieux de l'utiliser ?

Answer 1

Je ne l'utilise pas au quotidien, mais il est utilisé par les outils qui veulent améliorer les performances ; par exemple, Paint.NET utilise NGEN pendant l'installation (ou peut-être la première utilisation). Il est possible (mais je n'en suis pas sûr) que certains outils MS le fassent aussi.

En fait, le NGEN effectue une grande partie du JIT pour un assemblage en amont, de sorte qu'il y a très peu de retard lors d'un démarrage à froid. Bien sûr, dans la plupart des utilisations typiques, 100% du code n'est jamais atteint, donc d'une certaine manière, cela fait beaucoup d'économies. inutile mais il ne peut pas le dire à l'avance.

L'inconvénient, IMO, est que vous devez utiliser le GAC pour utiliser NGEN ; j'essaie d'éviter le GAC autant que possible, afin de pouvoir utiliser robocopy-deployment (vers les serveurs) et ClickOnce (vers les clients).

Answer 2

Oui, j'ai constaté une amélioration des performances. Mes mesures ont indiqué que les performances de démarrage étaient améliorées si je plaçais également mes assemblages dans le GAC, étant donné que mes assemblages ont tous un nom fort. Si vos assemblages ont un nom fort, NGen ne fera aucune différence sans utiliser le GAC. La raison en est que si vous avez des assemblages à nom fort qui ne sont pas dans le GAC, alors le runtime .NET valide que votre assemblage à nom fort n'a pas été altéré en chargeant l'assemblage géré entier depuis le disque afin de le valider, contournant ainsi l'un des principaux avantages de NGen.

Ce n'était pas une très bonne option pour mon application, car nous nous appuyons sur des assemblages communs à notre entreprise (qui ont également des noms forts). Les assemblages communs sont utilisés par de nombreux produits qui utilisent de nombreuses versions différentes, les mettre dans le GAC signifiait que si l'une de nos applications ne disait pas "utiliser une version spécifique" de l'un des assemblages communs, elle chargerait la version du GAC indépendamment de la version qui se trouvait dans son répertoire d'exécution. Nous avons décidé que les avantages de NGen ne valaient pas les risques.

Answer 3

Ngen réduit principalement le temps de démarrage de l'application .NET et le temps de travail de l'application. Mais il a quelques inconvénients (de CLR Via C# de Jeffrey Richter) :

Pas de protection de la propriété intellectuelle

Les fichiers NGen'd peuvent se désynchroniser

Performances inférieures en temps de chargement (rebasement/liaison)

Performances inférieures en matière de temps d'exécution

En raison de tous les problèmes que nous venons d'énumérer, vous devez être très prudent lorsque vous envisagez d'utiliser NGen.exe. Pour les applications côté serveur, NGen.exe n'a que peu ou pas de sens parce que seule la première demande du client subit une baisse de performance ; les demandes ultérieures du client s'exécutent à grande vitesse. Sur En outre, pour la plupart des applications serveur, une seule instance du code est nécessaire, de sorte qu'il n'y a pas d'avantage de jeu de travail. de l'ensemble de travail.

Pour les applications clientes, NGen.exe peut être utile pour améliorer le temps de démarrage ou pour réduire l'ensemble de travail si un assemblage est utilisé par plusieurs applications simultanément. ensemble de travail si un assemblage est utilisé par plusieurs applications simultanément. Même dans le cas où où un assembly n'est pas utilisé par plusieurs applications, NGen'ing un assembly pourrait améliorer le ensemble de travail. De plus, si NGen.exe est utilisé pour tous les assemblages d'une application cliente, le CLR n'aura pas besoin de charger la JIT. n'aura pas besoin de charger le compilateur JIT, ce qui réduira encore plus le nombre d'opérations. Bien sûr, si bien sûr, si un seul assemblage n'est pas NGen'd ou si le fichier NGen'd d'un assemblage ne peut pas être utilisé, le compilateur JIT se chargera, et l'ensemble de travail de l'application augmentera.

Answer 4

ngen est surtout connu pour améliorer le temps de démarrage (en éliminant la compilation JIT). Il peut améliorer (en réduisant le temps JIT) ou diminuer les performances globales de l'application (puisque certaines optimisations JIT ne seront pas disponibles).

.NET Framework lui-même utilise ngen pour de nombreux assemblages lors de l'installation.

Answer 5

Je l'ai utilisé mais juste à des fins de recherche. utilisez-le UNIQUEMENT si vous êtes sûr de l'architecture du processeur de votre environnement de déploiement (il ne changera pas).

mais laissez-moi vous dire que la compilation JIT n'est pas si mauvaise et si vous avez des déploiements dans des environnements à processeurs multiples (par exemple une application client Windows qui est souvent mise à jour) ALORS N'UTILISEZ PAS NGEN. c'est parce qu'un cache ngen valide dépend de nombreux attributs. si l'un d'entre eux échoue, votre assemblage retombe en JIT

Le JIT est clairement gagnant dans de tels cas, car il optimise le code à la volée en fonction de l'architecture du processeur sur lequel il est exécuté. (par exemple, il peut détecter s'il y a plus d'un processeur).

et clr s'améliore à chaque version, donc en bref, restez avec le JIT à moins que vous ne soyez absolument sûr de votre environnement de déploiement - même dans ce cas, vos gains de performance justifieraient à peine l'utilisation de ngen.exe (les gains seraient probablement de quelques centaines de ms) - imho - cela ne vaut pas la peine de faire des efforts

Consultez également ce lien très intéressant sur ce sujet - Compilation JIT et performances - Vers NGen ou pas ?