私は、アプリケーションのメモリ フットプリントを削減する任務を負っていWindows CE 5.0ます。マネージ DLL を使用してコードをプロセスのスロットに入れないようにすることを推奨している Rob Tiffany の非常に引用された記事に出くわしました。しかし、私には理解できないことがあります。
記事は言う
JIT コンパイラはスロットで実行されており、現在のコール スタックをコンパイルするために、必要に応じて 1 GB スペースから IL を取り込みます。
これは、マネージ DLL 内のすべてのコードが、最終的にプロセスのスロットに配置される可能性があることを意味します。これは共通領域にコードをロードしないことで他のプロセスに役立ちますが、このプロセスにどのように役立ちますか? FWIW記事はそれについて言及しています
また、内部で割り当てる必要があるメモリの量を減らします
私の唯一の考えは、コードがスロットに引き込まれるのと同じように、それもプッシュ/スワップアウトされるということです。しかし、それはただの推測であり、おそらく完全に間違っています。
CF アセンブリは、ネイティブ DLL のようにプロセス スロットに読み込まれません。実際には、メモリ マップト ファイルとしてアクセスされます。これは、DLL のサイズが事実上無関係であることを意味します。
マネージ ヒープもプロセス スロットではなく共有メモリにあるため、オブジェクトの割り当てによってプロセス スロットの断片化や OOM が発生する可能性ははるかに低くなります。
JITter は JIT だけではなく、永久に保持されます。必要なものをコンパイルし、GC 中に、使用されていない、またはしばらく使用されていないコンパイル済みコードを売り込む可能性があります。アセンブリ全体が JITT 化され、プロセスにゆっくりと取り込まれることは決してありません (小さなアセンブリの場合はそうかもしれませんが、それは確かに一般的ではありません)。
明らかに、一部のプロセス スロット メモリを使用して、いくつかのポインターやスタック ストレージなどを作成する必要がありますが、概して、マネージド コードはネイティブ コードよりもプロセス スロットの制限に与える影響がはるかに少なくなります。もちろん、大きなスタック、P/Invokes、ネイティブ割り当てなどで制限に達する可能性があります。
私の経験では、人々が CF アプリで最も頻繁に問題を起こすのは、GDI オブジェクトと描画に関するメモリです。ビットマップは多くのメモリを占有します。大部分は共有メモリにありますが、多くの場合 (ブラシ、ペンなどと一緒に) 作成し、キャッシュや再利用を行わないことが、マネージド アプリのメモリ フットプリントを大きくする原因となります。
もう少し詳細については、Compact Framework Memory Management に関するこの MSDN Webcast が古いものですが、今でも非常に関連性があります。