c# - ngen.exeを使用したことがありますか？

Question

ここで誰かがngenを使用したことがありますか？どこ？なぜ？パフォーマンスの改善はありましたか？いつ、どこで使用するのが理にかなっていますか？

score 31 · Accepted Answer

日常的には使用していませんが、パフォーマンスを向上させたいツールで使用されています。たとえば、Paint.NETはインストーラー中にNGENを使用します（または最初に使用する場合もあります）。一部のMSツールもそうする可能性があります（確かにはわかりませんが）。

基本的に、NGENは事前にアセンブリのJITの多くを実行するため、コールドスタートの遅延はほとんどありません。もちろん、最も一般的な使用法では、コードの100％に到達することはないため、いくつかの点でこれは多くの不要な作業を行いますが、事前にそれを知ることはできません。

欠点であるIMOは、NGENを使用するためにGACを使用する必要があることです。robocopy-deployment（サーバーへ）とClickOnce（クライアントへ）を使用できるように、GACをできるだけ避けようとしています。

score 19 · Accepted Answer

はい、パフォーマンスが向上しました。私の測定では、アセンブリはすべて強い名前が付けられているため、アセンブリもGACに入れると、起動パフォーマンスが向上することが示されました。アセンブリに強い名前が付けられている場合、NGenはGACを使用しなくても違いはありません。この理由は、GACにない強力な名前付きアセンブリがある場合、.NETランタイムは、管理対象アセンブリ全体をディスクからロードすることにより、強力な名前付きアセンブリが改ざんされていないことを検証し、回避することを検証できるためです。 NGenの主な利点の1つ。

これは私のアプリケーションにとってあまり良いオプションではありませんでした。なぜなら、私たちは会社の一般的なアセンブリに依存しているからです（これも強い名前が付けられています）。共通アセンブリは、多くの異なるバージョンを使用する多くの製品で使用されています。それらをGACに入れると、アプリケーションの1つが共通アセンブリの1つの「特定のバージョンを使用する」と言わなかった場合、何に関係なくGACバージョンが読み込まれます。バージョンは実行ディレクトリにありました。NGenのメリットはリスクに見合うものではないと判断しました。

score 9 · Accepted Answer

Ngenは、主に.NETアプリとアプリケーションのワーキングセットの起動時間を短縮します。ただし、いくつかの欠点があります（CLRからJeffrey RichterのC＃経由）：

知的財産保護なし

NGenのファイルが同期しなくなる可能性があります

劣ったロード時のパフォーマンス（リベース/バインディング）

実行時間のパフォーマンスが低い

上記のすべての問題があるため、NGen.exeの使用を検討する際は十分に注意する必要があります。サーバー側のアプリケーションの場合、最初のクライアント要求のみがパフォーマンスの低下を経験するため、NGen.exeはほとんどまたはまったく意味がありません。将来のクライアント要求は高速で実行されます。さらに、ほとんどのサーバーアプリケーションでは、コードのインスタンスが1つだけ必要なため、ワーキングセットのメリットはありません。

クライアントアプリケーションの場合、アセンブリが複数のアプリケーションで同時に使用される場合、NGen.exeは起動時間を改善したり、ワーキングセットを削減したりするのに意味があります。アセンブリが複数のアプリケーションで使用されていない場合でも、アセンブリをNGen化すると、ワーキングセットが向上する可能性があります。さらに、NGen.exeがすべてのクライアントアプリケーションのアセンブリに使用されている場合、CLRはJITコンパイラをまったくロードする必要がないため、ワーキングセットがさらに削減されます。もちろん、1つのアセンブリだけがNGenされていない場合、またはアセンブリのNGenされたファイルを使用できない場合は、JITコンパイラがロードされ、アプリケーションのワーキングセットが増加します。

score 7 · Accepted Answer

ngen（JITコンパイルを排除することにより）起動時間を改善することで主に知られています。（JIT時間を短縮することにより）改善するか、アプリケーションの全体的なパフォーマンスを低下させる可能性があります（一部のJIT最適化が利用できないため）。

.NET Framework自体はngen、インストール時に多くのアセンブリに使用されます。

score 1 · Accepted Answer

私はそれを使用しましたが、研究目的のためだけです。デプロイメント環境のCPUアーキテクチャーについて確信がある場合にのみ使用してください（変更されません）

ただし、JITコンパイルはそれほど悪くはなく、複数のCPU環境（たとえば、頻繁に更新されるWindowsクライアントアプリケーション）に展開している場合は、NGENを使用しないでください。thats coz有効なngenキャッシュは、多くの属性に依存します。これらのいずれかが失敗した場合、アセンブリは再びjitにフォールバックします

JITは、実行中のCPUアーキテクチャに基づいてコードをオンザフライで最適化するため、このような場合に明らかに勝者です。（たとえば、CPUが1つ以上あるかどうかを検出できます）

clrはリリースごとに改善されているため、デプロイメント環境に確信が持てない限り、JITを使い続けてください。それでも、ngen.exeを使用した場合のパフォーマンスの向上はほとんど正当化されません（おそらく数百ミリ秒で向上します）-imho-努力する価値はありません

また、このトピックに関するこの本当に素晴らしいリンクを確認してください-JITコンパイルとパフォーマンス-NGenへまたはNGenへではありませんか？

score 0 · Accepted Answer

はい、CPUを集中的に使用する小さなexeで試してみましたが、ngenでは少し遅くなりました!

ngen イメージを複数回インストールおよびアンインストールし、ベンチマークを実行しました。

私は常に次の再現可能な時間を得ました +/- 0.1 秒: 33.9 秒なし、35.3 秒あり

score 0 · Accepted Answer

はい。起動時間を短縮するために WPF アプリケーションで使用されます。起動時間が 9 秒から 5 秒になりました。私のブログでそれについて読んでください：

私は最近、NGEN がいかに優れたパフォーマンスを発揮できるかを発見しました。私が現在取り組んでいるアプリケーションには、データアクセス層 (DAL) が生成されています。データベーススキーマは非常に大きく、一部のデータ (値のリスト) を直接 DAL に生成します。結果: 多くのフィールドと多くのメソッドを持つ多くのクラス。JIT オーバーヘッドは、アプリケーションのプロファイリング時に頻繁に表示されますが、JIT コンパイルと NGEN を検索した後、それだけの価値はありませんでした。管理が私の主な関心事であるインストール時間のオーバーヘッドにより、私は兆候を無視し、代わりにアプリケーションに機能を追加することに集中しました。アーキテクチャを 64 ビットマシンで実行する「任意の CPU」に変更すると、事態はさらに悪化しました。プロファイラーが問題領域の JIT オーバーヘッドのみを示し、1 つのステートメントで最大 10 秒間、アプリケーションがハングアップしました。NGEN は問題を解決しました。ステートメントは 10 秒から 1 ミリ秒になりました。このステートメントは起動手順の一部ではなかったので、アプリケーション全体を NGEN 化すると起動時間に何ができるかを知りたいと思っていました。8 秒から 3.5 秒になりました。

結論: アプリケーションで NGEN を試すことを強くお勧めします!

score 0 · Accepted Answer

JITコンパイルに関するMehrdad Afshariのコメントへの追加として。XmlSerializer と 64 ビットシステムで SGEN を介して多くのプロパティを持つクラスをシリアル化する場合、NGEN コンボは潜在的に巨大な(この場合はギガバイトと分) 効果があります。

詳細はこちら: XmlSerializer の起動時に 64 ビットシステムでのパフォーマンスが大幅に低下する特に Nick Martyshchenko の回答を参照してください。

c# - ngen.exeを使用したことがありますか？

8 に答える 8

Related

Reference