.NET Framework 2.0 / 3.0 / 3.5を使用するオーバーヘッドに関する具体的な情報はありますか？
私は主にインスタンスごとのオーバーヘッドに関心があり、インスタンスの数に関係なく「固定コスト」があるかどうかに関心があります。たとえば、.NET Frameworkアプリケーションのインスタンスが300個実行されているターミナルサービス環境では、Just-のインスタンスは1つだけです。インタイムコンパイラ？
近似アルゴリズムを取得できれば素晴らしいと思います。たとえば、インスタンスあたり10MB+JITの場合は50MBです。
アンマネージコードとまったく同じように機能します。CLR、JITコンパイラ、および.NET Frameworkアセンブリは、マネージコードを実行するすべてのプロセスによって共有されるDLLです。コードの1つのコピーのみがRAMにロードされ、すべてのプロセスが仮想メモリページをその1つのコピーにマップします。
マネージコードは、共有できない種類のアンマネージコードよりもプライベートバイトが多い傾向があります。これはまず、JITコンパイラが原因で、あるプロセスと別のプロセスで同じではないアドレスでオンザフライでマシンコードを生成します。そして、ローダーとガベージコレクションされたヒープは少し頑丈になる傾向があります。
Ngen.exeを使用して、JITコンパイラのオーバーヘッドを排除します。そのため、.NET Frameworkアセンブリは共有されており、フレームワークをマシンにインストールしたときにNgen化されました。ヒープについては何もできませんが、アンマネージコードではそれほど違いはありません。