プロセス間でコードを共有する場合は、ネイティブ イメージによってメモリ使用を大いに改善できます。ネイティブ イメージは Windows PE ファイルのため、.dll ファイルの単一のコピーを複数のプロセスで共有できます。これに対して、JIT コンパイラが生成するネイティブ コードは、プライベート メモリに格納されるため共有できません。

ターミナル サービスで実行されるアプリケーションも、共有されたコード ページの恩恵を受けることができます。

さらに、JIT コンパイラを読み込まないため、各アプリケーション インスタンスが使用する固定メモリの量も減らすことができます。

Ngen.exe によってアセンブリをプリコンパイルすることにより、一部のアプリケーションの起動時間が短縮されます。一般に、最初のアプリケーションが起動されると、その後のアプリケーションが使用する共有コンポーネントが読み込まれるため、アプリケーションがコンポーネント アセンブリを共有している場合にアプリケーションの起動時間が短縮されます。アプリケーションのすべてのアセンブリをハード ディスクから読み込む必要があるコールド スタートでは、ハード ディスクのアクセス時間の影響の方が大きいため、ネイティブ イメージから受け取る恩恵はそれほど大きくありません。

メイン アプリケーション アセンブリにハード バインディングされているすべてのイメージは同時に読み込む必要があるため、ハード バインディングは起動時間に影響します。

メモ
厳密な名前が付いている共有コンポーネントがある場合は、それをグローバル アセンブリ キャッシュに置きます。ローダーは厳密な名前が付いているアセンブリに対してグローバル アセンブリ キャッシュには実行されない余分な検証を実行するため、ネイティブ イメージを使用することによって得られる起動時間の短縮の恩恵を受けることができません。

ネイティブ イメージは Windows PE ファイルのため、他の実行可能ファイルと同様に再ベースの問題があります。ハード バインディングを使用する場合、再配置のパフォーマンス コストはさらに増大します。

ネイティブ イメージにベース アドレスを設定するには、コンパイラの適切なオプションを使用してアセンブリのベース アドレスを設定します。Ngen.exe は、このベース アドレスをネイティブ イメージに使用します。

メモ
ネイティブ イメージは、元になるマネージ アセンブリより大きくなります。ベース アドレスは、この大きなサイズを考慮して算出する必要があります。

dumpbin.exe などのツールを使用すると、ネイティブ イメージの推奨ベース アドレスを表示できます。

次の一般的な考慮事項とアプリケーションの考慮事項は、アプリケーションにネイティブ イメージを使用するかどうかを評価する際に役立ちます。

• ネイティブ イメージでは、JIT コンパイル、タイプ セーフ検証などの多くの起動時アクティビティが不要なため、MSIL より読み込みが高速になります。

• ネイティブ イメージでは JIT コンパイラが不要なため、必要な初期作業セットが少なくてすみます。

• ネイティブ イメージによって、プロセス間でコードを共有できます。

• ネイティブ イメージは MSIL アセンブリよりも多くのハード ディスク容量を必要とし、生成にかなりの時間を要する場合があります。

• ネイティブ イメージは保持する必要があります。

  • 元のアセンブリまたはその依存関係のいずれかに対してサービスを提供する場合は、イメージを再生成する必要があります。

  • アプリケーションまたはシナリオごとに異なるネイティブ イメージを使用する場合、1 つのアセンブリで複数のネイティブ イメージが必要な場合があります。たとえば、2 つのアプリケーションの構成情報で、同じ依存アセンブリに対してバインディング決定が異なる場合です。

  • ネイティブ イメージは管理者が作成する必要があります。つまり Administrators グループの Windows アカウントから作成します。

このような一般的な考慮事項に加えて、ネイティブ イメージによってパフォーマンスが向上するかどうかを検討する場合は、アプリケーションの特性も考慮する必要があります。

• 多くの共有コンポーネントを使用する環境でアプリケーションを実行する場合は、ネイティブ イメージによってコンポーネントを複数のプロセスで共有できます。

• アプリケーションが複数のアプリケーション ドメインを使用する場合は、ネイティブ イメージによってドメイン間でコード ページを共有できます。

  メモ
  .NET Framework Version 1.0 と 1.1 では、アプリケーション ドメイン間でネイティブ イメージを共有することはできません。Version 2.0 では可能です。

• アプリケーションをターミナル サーバーで実行する場合は、ネイティブ イメージによってコード ページを共有できます。

• サイズの大きなアプリケーションでは、一般にネイティブ イメージにコンパイルすることでパフォーマンスが向上します。サイズの小さなアプリケーションでは、一般にあまり有効ではありません。

• 長時間実行するアプリケーションでは、ランタイム JIT コンパイルのパフォーマンスの方がネイティブ イメージよりも若干優れています。ハード バインディングによって、このパフォーマンスの違いをある程度緩和できます。

アセンブリに DependencyAttribute を適用して、指定された依存関係が読み込まれるかどうかを示します。System.Runtime.CompilerServices.LoadHint.Always は、ハード バインディングが適切であることを示し、Default は依存関係の既定値を使用する必要があることを示し、Sometimes はハード バインディングが適切ではないことを示します。

2 つの依存関係があるアセンブリのための属性のコードを次に示します。最初の依存関係 (Assembly1) はハード バインディングに適しており、2 番目 (Assembly2) は適していません。

Imports System.Runtime.CompilerServices
<Assembly:DependencyAttribute("Assembly1", LoadHint.Always)>
<Assembly:DependencyAttribute("Assembly2", LoadHint.Sometimes)>

using System.Runtime.CompilerServices;
[assembly:DependencyAttribute("Assembly1", LoadHint.Always)]
[assembly:DependencyAttribute("Assembly2", LoadHint.Sometimes)]

using namespace System::Runtime::CompilerServices;
[assembly:DependencyAttribute("Assembly1", LoadHint.Always)];
[assembly:DependencyAttribute("Assembly2", LoadHint.Sometimes)];

アセンブリ名には、ファイル名拡張子は含めません。表示名を使用できます。

既定のバインディング ヒントは、依存するアプリケーションが即座に頻繁に使用するアセンブリだけに必要です。そのようなアセンブリには、System.Runtime.CompilerServices.LoadHint.Always と共に DefaultDependencyAttribute を適用して、ハード バインディングを使用することを指定します。

メモ
System.Runtime.CompilerServices.LoadHint.Always 以外の値を使用してこの属性を適用しても、この属性をまったく適用しない場合と結果は同じため、このカテゴリに属さない .dll アセンブリに DefaultDependencyAttribute を適用する理由はありません。

Microsoft では、DefaultDependencyAttribute を使用して、mscorlib.dll などのごく一部の .NET Framework のアセンブリの既定値としてハード バインディングを指定します。

Ngen.exe を使用してアセンブリのネイティブ イメージを作成する場合、出力は指定したコマンド ライン オプションおよび使用するコンピュータ上の設定に依存します。影響のある設定は次のとおりです。

• .NET Framework Version。

• オペレーティング システムのバージョン (Windows 9x ファミリから Windows NT ファミリに変更した場合)。

• アセンブリの正確な ID (ID は再コンパイル時に変更されます)。

• アセンブリが参照するすべてのアセンブリの正確な ID (ID は再コンパイル時に変更されます)。

• セキュリティ関連の要因。

Ngen.exe は、ネイティブ イメージを生成するときに上記の情報を記録します。アセンブリが実行されると、ランタイムは、コンピュータの現在の環境と一致するオプションおよび設定を指定して生成されたネイティブ イメージを検索します。一致するネイティブ イメージが見つからない場合、ランタイムはアセンブリを JIT コンパイルに戻します。コンピュータの設定および環境が次のように変更されると、ネイティブ イメージは無効になります。

• .NET Framework Version。

  更新を .NET Framework に適用すると、Ngen.exe を使用して作成したすべてのネイティブ イメージは、無効になります。したがって、.NET Framework の更新では、常に Ngen Update コマンドが実行されてすべてのネイティブ イメージが再生成されます。.NET Framework は、インストールする .NET Framework ライブラリの新しいネイティブ イメージを自動的に作成します。

• オペレーティング システムのバージョン (Windows 9x ファミリから Windows NT ファミリに変更した場合)。

  たとえば、コンピュータで稼動しているオペレーティング システムのバージョンが Windows 98 から Windows XP に変更されると、ネイティブ イメージ キャッシュに格納されたすべてのネイティブ イメージは無効になります。ただし、オペレーティング システムを Windows 2000 から Windows XP に変更した場合は、イメージは無効になりません。

• アセンブリの正確な ID。

  アセンブリを再コンパイルすると、アセンブリの対応するネイティブ イメージは無効になります。

• アセンブリが参照するすべてのアセンブリの正確な ID。

  マネージ アセンブリを更新する場合、そのアセンブリに直接または間接に依存するすべてのネイティブ イメージが無効になるため、これらを再生成する必要があります。これには、通常の参照と強くバインドされた依存関係も含まれます。ソフトウェアの更新を適用するときには、インストール プログラムで Ngen Update コマンドを実行して、依存するすべてのネイティブ イメージを再生成する必要があります。

• セキュリティ関連の要因。

  アセンブリに事前に与えられていたアクセス許可を制限するマシン セキュリティ ポリシーを変更すると、そのアセンブリのコンパイル済みのネイティブ イメージが無効になることがあります。

  共通言語ランタイムがコード アクセス セキュリティを管理する方法とアクセス許可を使用する方法の詳細については、「コード アクセス セキュリティ」を参照してください。