納期がギリギリでも高速化しなくてはならないことがあります。 そんな時に役に立つ、ソースを変更せずにコンパイル時や実行時の設定だけで高速化する方法を紹介します。 以下、効果が高く重要な順に行きます。 使用するアセンブリ（ＤＬＬ）のロード時間を高速化する 呼び出すアセンブリ（ＤＬＬ）が２個以上あるなら、ベースアドレスを変更する 必要とするアセンブリの検索をプローブに頼っていませんか？プローブによる呼び出しはかなり低速です。「.NET Frameworkアプリは起動が異常に遅い」などという人は、大抵、この辺の知識か、ＪＩＴに対する理解が足りていません。厳密名をつけ、アセンブリをＧＡＣに導入することを検討してください。 ベースアドレスの変更はWindows開発の常識です。解説は他のサイトに任せます。 次にＣＰＵが２個以上あるサーバプログラムでは以下の事も検討すべきです。 ガベージコレクタを変更して

.Netアプリの起動の速度向上�A 起動が遅いことについては要因が２つある。 １．ＪＩＴによるもの。これに関しては、ngenにより改善可能。 ２．必要なメモリ使用量と仮想記憶サイズの合計が大きいこと。 起動時にその多くを実メモリに一旦ロードするためにページングなどが 多く起きる、これによる遅延が相当に大きい。 但し、一度起動してしまえば実際に必要な箇所は限られるので実メモリ （ワーキングセット）は減少し安定してくる。 この問題を解決するには基本的に実メモリを増やすしかない。 CLRの起動時に作成されるドメインは下記の3種類が作成される。 1)　System Domain 2)　Shared Domain 3)　Default AppDomain System Domainは、InterfaceVtableMaps(インターフェース仮想関数へ

.Netアプリの起動の速度向上 .Netアプリの起動が遅いのは知られたことですが、利用者には起動が遅いのは .Netである為、仕方ないのですよってのが通じるのかって話ですよ。 それなら、.Net以外で製造してくれってことになりかねません。 OSをビスタにすれば、起動は速くなるようですが、一般企業のPCがビスタに変わ るのは、まだまだ数年以上も先の話でしょう。 確かにアプリケーションの実行を考えると初回起動時に遅いのは、それほど問題 ではならないかもしれませんが、初回起動が遅いためにユーザーが不安になるケ ースは多いと思います。←問題かも(^^; スプラッシュウィンドウを出して動いているって見せればいいのかも知れませんが .Netでは、それすら起動が遅いので、にっちもさっちもです。 ってことで、アンマネージド(Win32系　VB6など)なスプラッシュ

Windowsにおいて、アセンブリはDLLで実装されています。 マネージドアプリ(EXE)からアセンブリ(DLL)を読み込む場合、一般的なWin32アプリケーションがEXEファイルからDLLを探索する手順とは異なるルールを採用しています。 参考までに、Win32のネイティブなDLLは、以下の順番で検索します（※１）。 レジストリの「knowndll」リスト 実行ファイルのディレクトリ カレントディレクトリ システムディレクトリ Windowsディレクトリ 環境変数の「PATH」 しかし、最後まで名前に頼るというのが、安全ではないと考えられたため、「.NETのアセンブリ」ではより確実な方法な以下の順序に変更されました。 構成ファイル(app.config, machine.config等)の<codebase>要素 以前に読み込んだアセンブリのバインド履歴 グローバルアセンブリキャッシュ（Ｇ

■グローバル・アセンブリ・キャッシュ（GAC） グローバル・アセンブリ・キャッシュ（GAC）とは、名前のとおりマシン全体でグローバルに参照可能なアセンブリの配置場所だ。.NET Frameworkをインストールすると、デフォルトでは「%Systemroot%\assembly」フォルダ以下がGACとして設定される。GACは特殊なフォルダ構造なので、ここに単純にファイルをコピーするようなことはできない。実際、エクスプローラで「%Systemroot%\assembly」フォルダを見てみると、アセンブリの名前を一覧表示するシェル拡張が起動される。 GACにアセンブリをインストールするには、2つ方法がある。1つはエクスプローラを使って、GACにファイルをドロップする方法だ。アセンブリのプライマリ・モジュール・ファイルをこのフォルダにドロップするだけで、アセンブリがGACに登録される。もう1つはg