私たちは Winforms アプリケーションを開発しており、起動時間を最適化しています。
アプリは 64 ビット Vista マシンで実行されます。私たちのテストでは、直感に反するような結果が得られました。それ以外はすべて同じで、32 ビットと 64 ビットのロードを半分の時間でターゲットにしています。なぜ誰かが光を当てることができますか？
ありがとう。
[編集] ClickOnce を介してアプリをデプロイします。これは、独自のサンドボックスでアプリを開始する調査から得られたものです。したがって、常にコールド スタートになるため、ここでパフォーマンスを改善しようとしても無駄でした。
私たちの主な問題は、プロジェクトに 32 ビット dll が存在することでした。プロジェクトを x86 でターゲットにすると (x64 で実行されますが)、ロード時間が半分に短縮されました。[/編集]
.NET 3.5 SP1 では、信頼できる場所から取得したアセンブリの厳密な名前を検証しなくなるため、起動時のパフォーマンスが向上します。私の本では少し物議をかもしていますが、やや擁護できます。
CLR の 64 ビット バージョンもこの時間のかかる手順をバイパスするかどうかを確認しました。DLL に署名し、GAC に入れ、1 バイトにパッチを当てました。アセンブリをロードするときに苦情はありません。したがって、違いを説明するのは SP1 の起動環境の改善ではありません。
起動時間のその他の要因は次のとおりです。 - ディスクからの CLR の読み込み (コールドスタートのみ) - 依存アセンブリの Groveling - 起動コードの JIT コンパイル
コールドスタートが要因である可能性があります.CLRの64ビットバージョンがロードされている他のプロセスが実行されていない可能性があります. テスト中にダミーの .NET アプリを実行することで、簡単に排除できます。
同じ理由で、アセンブリをうろついても時間がかかる場合があります。.NET アセンブリの 64 ビット ngen-ed イメージがファイル システム キャッシュにある可能性はほとんどありません。繰り返しになりますが、同じアセンブリに依存するダミー アプリを使用すると、簡単に削除できます。
64 ビットの JITter は非常に難しい問題です。恣意的な呼び出しは、MSFT が 32 ビット JITter ほどパフォーマンスの高いものを作るのに多くの時間を費やさなかったと仮定することです。ただし、証拠によって裏付けられるものは何もありません。測定も難しく、Assembly.Load でアセンブリをロードしてから、クラス コンストラクターが可能な限り多くのコードを呼び出す Activator.CreateInstance() の時間を計測する必要があります。
64 ビット バージョンでは通常、ヒープで 2 倍のメモリを使用します。各ポインターは 2 倍のスペースを必要とし、.NET はポインターでいっぱいです。起動はメモリの初期化に大きく影響されるため、これが追加のオーバーヘッドの一部を占める可能性があります。Donald Knuth の 64 ビット ポインタに関する炎も参照してください。
Microsoft によると、.Net 3.5 SP1 には起動パフォーマンスに関するかなりの作業 (一部のアプリでは最大 40% の改善) が含まれていることに注意してください。