ソースを変えずに高速化する（.NET Framework）

納期がギリギリでも高速化しなくてはならないことがあります。

そんな時に役に立つ、ソースを変更せずにコンパイル時や実行時の設定だけで高速化する方法を紹介します。

以下、効果が高く重要な順に行きます。

• 使用するアセンブリ（ＤＬＬ）のロード時間を高速化する
• 呼び出すアセンブリ（ＤＬＬ）が２個以上あるなら、ベースアドレスを変更する

必要とするアセンブリの検索をプローブに頼っていませんか？プローブによる呼び出しはかなり低速です。「.NET Frameworkアプリは起動が異常に遅い」などという人は、大抵、この辺の知識か、ＪＩＴに対する理解が足りていません。厳密名をつけ、アセンブリをＧＡＣに導入することを検討してください。

ベースアドレスの変更はWindows開発の常識です。解説は他のサイトに任せます。

次にＣＰＵが２個以上あるサーバプログラムでは以下の事も検討すべきです。

• ガベージコレクタを変更してみる

ガベージコレクタを選べるのはご存知でしょうか？クライアント用とサーバ（マルチプロセッサ）用です。特に、.NET Framework 1.1 SP1 以降ではapp.configで簡単に変更できます。サーバプログラムを開発しているのに区別がついていない人は再確認してください。

やや強引な手もあります。

• ネイティブコードに変換する（NGEN使用）
• 複数のアセンブリを結合する

.NET Frameworkで生成されたコードをngenというユーティリティを使ってコンパイルしてしまいます。Windowsフォームの部分だけでもコンパイルしておくと結構違うらしいです。しかし、アプリケーションドメインが違うアセンブリに対して適用できません（※１）し、全体が高速化するとは限りません。

また、複数のアセンブリを結合する事によって、ロード時間自体が短縮する場合もあります。これらの結合にはILMargeというツールを使うと良いでしょう。そもそも、一緒に使う機能が同一アセンブリになっていない時点で設計ミスです。

次にかなり強引な手です。

• アセンブリをCOMと相互運用するモジュールとして扱う場合、タイプライブラリエクスポータ（Tlbexp.exe）に/unsafeオプションを適用する
• machine.configを変更する

上記は、セキュリティチェックを省くことによる高速化です。オートメーションを利用している場合は大きな効果が得られた時もありました（最も、行き来が多い時点で設計ミスです）。

machine.configには「.NET Framework全体の挙動」に関するパラメータを色々書くことが出来ます。ASP.NET系のアプリケーションではこれで改善する事も多いですが、逆にいうとサーバプログラム以外がmachine.configを変更することは許されないと思います。

以上、MSDNから抜粋したメモのうち、効果のあったものだけを紹介しました。

ちなみに、コードを変更して良い場合なら、スレッディングモデルとマーシャリングを適切に設計する事から始めましょう。この辺はCOMを知っている人は分かっているでしょうし、気が向いたら別のカテゴリに書くことにします。

※１ .NET Framework 2.0以降は出来るとの記述あり。実現手段などの詳細未確認。

---

[MSDN] .NET アプリケーションのパフォーマンスとスケーラビリティの向上