この回答には、かなり興味深い主張があります。GAC に余分な未使用の .NET アセンブリがあると、パフォーマンスが低下するというものです。
具体的にはX.Y.Z
、マシン GAC にアセンブリがあり、そのマシン上のプログラムがこのアセンブリを使用しておらず、GAC にこのアセンブリがあるとパフォーマンスが低下する可能性があるという主張です。
本当?この点に関する詳細なデータはありますか?
この回答には、かなり興味深い主張があります。GAC に余分な未使用の .NET アセンブリがあると、パフォーマンスが低下するというものです。
具体的にはX.Y.Z
、マシン GAC にアセンブリがあり、そのマシン上のプログラムがこのアセンブリを使用しておらず、GAC にこのアセンブリがあるとパフォーマンスが低下する可能性があるという主張です。
本当?この点に関する詳細なデータはありますか?
これはコールドスタートに影響します。これは、マネージコードで最も注目されるパフォーマンス特性です。これは、はるかに遅く、最も目立つためです。マネージコードには、アセンブリとngen-ed DLLの両方で、検索するDLLがたくさんあります。これはハードドライブでは遅く、ファイルシステムキャッシュにまだ何も入っていないときにファイルを掘り起こすのに時間がかかります。ディレクトリが大きいほど、検索に時間がかかります。
マネージコードだけの問題ではありません。多くのDLLを使用するネイティブプログラムにもこの問題があります。そのため、OfficeアプリやAcrobat Readerなどの大きなプログラムは「オプティマイザー」を使用します。これはログイン時に開始される小さなプログラムで、メインプログラムが必要とするDLLのセットに触れるだけです。ファイルシステムキャッシュをウォーミングアップします。そして、初めてログインするときに本当に開始したいプログラムを実際に遅くします。私はいつもそれらを削除しますが、それらは元に戻す習慣があります、特にAdobeはそのように吸います。Windows Superfetchは優れたソリューションであり、実際の使用状況に基づいて、実行可能ファイルのセットを動的に事前キャッシュに調整します。
もちろん、GACからアセンブリを実際に削除することは現実的な解決策ではありません。とにかく効果は小さいです。