はい、パフォーマンスが向上しました。私の測定では、アセンブリはすべて強い名前が付けられているため、アセンブリもGACに入れると、起動パフォーマンスが向上することが示されました。アセンブリに強い名前が付けられている場合、NGenはGACを使用しなくても違いはありません。この理由は、GACにない強力な名前付きアセンブリがある場合、.NETランタイムは、管理対象アセンブリ全体をディスクからロードすることにより、強力な名前付きアセンブリが改ざんされていないことを検証し、回避することを検証できるためです。 NGenの主な利点の1つ。
これは私のアプリケーションにとってあまり良いオプションではありませんでした。なぜなら、私たちは会社の一般的なアセンブリに依存しているからです（これも強い名前が付けられています）。共通アセンブリは、多くの異なるバージョンを使用する多くの製品で使用されており、GACに配置すると、アプリケーションの1つが共通アセンブリの1つの「特定のバージョンを使用する」と言わなかった場合、何に関係なくGACバージョンが読み込まれます。バージョンは実行ディレクトリにありました。 NGenのメリットはリスクに見合う価値がないと判断しました。
日常的には使用していませんが、パフォーマンスを向上させたいツールで使用されています。たとえば、Paint.NETはインストーラー中にNGENを使用します（または最初に使用する場合もあります）。一部のMSツールもそうする可能性があります（確かにはわかりませんが）。
基本的に、NGENはアセンブリのJITの多くを事前に実行するため、コールドスタートの遅延はほとんどありません。もちろん、最も一般的な使用法では、コードの100％に到達することはないため、いくつかの点でこれは多くの不要動作します-しかし、事前にそれを知ることはできません。
欠点であるIMOは、NGENを使用するためにGACを使用する必要があることです。 robocopy-deployment（サーバーへ）とClickOnce（クライアントへ）を使用できるように、GACをできるだけ避けようとしています。
Ngenは主に、.NETアプリとアプリケーションのワーキングセットの起動時間を短縮します。しかし、いくつかの欠点があります（Jeffrey RichterのCLR Via C＃から）：
知的財産保護なし
NGenされたファイルが同期しなくなる可能性があります
劣ったロード時のパフォーマンス（リベース/バインディング）
実行時間のパフォーマンスが低い
上記のすべての問題があるため、NGen.exeの使用を検討する際には十分に注意する必要があります。サーバー側アプリケーションの場合、最初のクライアント要求のみがパフォーマンスの低下を経験するため、NGen.exeはほとんどまたはまったく意味がありません。将来のクライアント要求は高速で実行されます。さらに、ほとんどのサーバーアプリケーションでは、コードのインスタンスが1つだけ必要なため、ワーキングセットのメリットはありません。
クライアントアプリケーションの場合、アセンブリが複数のアプリケーションで同時に使用されている場合、NGen.exeは起動時間を改善したり、ワーキングセットを削減したりするのに意味があります。アセンブリが複数のアプリケーションで使用されていない場合でも、アセンブリをNGenすることでワーキングセットを改善できます。さらに、NGen.exeがすべてのクライアントアプリケーションのアセンブリに使用されている場合、CLRはJITコンパイラをまったくロードする必要がないため、ワーキングセットがさらに削減されます。もちろん、1つのアセンブリだけがNGenされていない場合、またはアセンブリのNGenされたファイルを使用できない場合は、JITコンパイラがロードされ、アプリケーションのワーキングセットが増加します。
ngenは、（JITコンパイルを排除することにより）起動時間を改善することで主に知られています。 （JIT時間を短縮することにより）改善するか、アプリケーションの全体的なパフォーマンスを低下させる可能性があります（一部のJIT最適化が利用できないため）。
.NET Framework自体は、インストール時に多くのアセンブリにngenを使用します。
私はそれを使用しましたが、研究目的のためだけです。デプロイメント環境のCPUアーキテクチャーについて確信がある場合にのみ使用してください（変更されません）
ただし、JITコンパイルはそれほど悪くはなく、複数のCPU環境（たとえば、頻繁に更新されるWindowsクライアントアプリケーション）にデプロイする場合は、NGENを使用しないでください。 thatscoz有効なngenキャッシュは多くの属性に依存します。これらのいずれかが失敗した場合、アセンブリは再びjitにフォールバックします
JITは、実行中のCPUアーキテクチャに基づいてコードをオンザフライで最適化するため、このような場合には明らかに勝者です。 （たとえば、CPUが1つ以上あるかどうかを検出できます）
clrはリリースごとに改善されているので、デプロイメント環境に確信が持てない限り、JITを使い続けてください。それでも、ngen.exeを使用してもパフォーマンスの向上は正当化されません（おそらく数百ミリ秒で向上します）-imho-努力する価値はありません
このトピックに関するこの本当の素敵なリンクもチェックしてください- JITコンパイルとパフォーマンス-NGenへかそうでないか？
はい。起動時間を短縮するためにWPFアプリケーションで使用されます。起動時間は9秒から5秒になりました。私の ブログ でそれについて読んでください：
私は最近、NGENがパフォーマンスにどれほど優れているかを発見しました。私が現在取り組んでいるアプリケーションには、生成されたデータアクセス層（DAL）があります。データベーススキーマは非常に大きく、一部のデータ（値のリスト）もDALに直接生成します。結果：多くのフィールドと多くのメソッドを持つ多くのクラス。アプリケーションのプロファイリング時にJITオーバーヘッドが頻繁に発生しましたが、JITコンパイルとNGEN Iを検索した後、それだけの価値はありませんでした。インストール時のオーバーヘッドは、管理が私の主な関心事であり、兆候を無視し、代わりにアプリケーションに機能を追加することに集中しました。アーキテクチャを64ビットマシンで実行される「任意のCPU」に変更すると、状況はさらに悪化しました。プロファイラーが問題領域でJITオーバーヘッドのみを表示し、1つのステートメントで最大10秒間アプリケーションがハングするという経験がありました。 NGENは問題を解決しました：ステートメントは10秒から1ミリ秒になりました。このステートメントは起動手順の一部ではなかったので、アプリケーション全体のNGENが起動時に何ができるかを知りたくなりました。 8秒から3.5秒になりました。
結論：NGENにアプリケーションを試してみることを強くお勧めします。
JITコンパイルに関するMehrdadAfshariのコメントへの追加として。 XmlSerializerおよび64ビットシステムでSGENを介して多くのプロパティを持つクラスをシリアル化する場合、NGENコンボには潜在的に巨大な（この場合はギガバイトと分）効果。
詳細はこちら： XmlSerializerの起動64ビットシステムでのパフォーマンスの大幅な低下 特にNickMartyshchenkoの回答を参照してください。
はい、CPUを集中的に使用する小さな単一のexeで試してみましたが、ngenでは少し遅くなりました。
Ngenイメージを複数回インストールおよびアンインストールし、ベンチマークを実行しました。
私は常に次の時間を再現可能+/- 0.1秒にしました：33.9秒なし、35.3秒あり