WPFアプリケーションの起動が遅くなるのはなぜですか？

Question

私はWPFアプリケーションの起動が時にはかなり遅いことに気付きました。原因は、要素の初期化またはDLLの読み込みまたは何か他の人が知っていますか？

Answer 1

以下this MSDN article on Improving WPF applications startup timeから抽出されたテキスト（編集：今WPF Application Startup Timeにマージ）

アプリケーション起動時間

大きく変化することができる開始するWPFアプリケーションに必要とされる時間の量。このトピックでは、Windows Presentation Foundation（WPF）アプリケーションの認識時間と実際の起動時間を短縮するさまざまな手法について説明します。アプリケーションは、システムの再起動後に初めて起動する、またはアプリケーションを起動したときに、それを閉じ、その後、長い期間の後に再びそれを起動したときにコールドスタートアップが発生した冷間始動とWarmStartup

を理解

時間の。アプリケーションが起動するときに、必要なページ（コード、静的データ、レジストリなど）がWindowsメモリマネージャのスタンバイリストに存在しない場合は、ページフォルトが発生します。ページをメモリに読み込むには、ディスクにアクセスする必要があります。

主要な共通言語ランタイム（CLR）コンポーネントのほとんどのページが既にメモリに読み込まれているため、高価なディスクアクセス時間が節約されます。そのため、管理対象アプリケーションは2回目の実行時に高速に起動します。

がアプリケーションを起動し、最初のUIを表示する間に有意な、避けられない遅延がある場合にはスプラッシュスクリーン

を実装し、スプラッシュ画面を使用して知覚される起動時間を最適化します。このアプローチは、ユーザーがアプリケーションを開始した直後にイメージを表示します。アプリケーションが最初のUIを表示する準備ができたら、スプラッシュ画面が消えます。 .NET Framework 3.5 SP1以降では、SplashScreenクラスを使用してスプラッシュ画面を実装できます。詳細については、How to: Add a Splash Screen to a WPF Applicationを参照してください。

ネイティブWin32グラフィックスを使用して独自のスプラッシュ画面を実装することもできます。 Runメソッドが呼び出される前に実装を表示します。

遅い冷間始動の原因を特定し、スタートアップコードに

を分析します。ディスクI/Oが原因である可能性がありますが、必ずしもそうであるとは限りません。一般に、ネットワーク、Webサービス、ディスクなどの外部リソースの使用を最小限に抑える必要があります。

実行する前に、他の実行中のアプリケーションやサービスがマネージコードやWPFコードを使用していないことを確認してください。

再起動後すぐにWPFアプリケーションを起動し、表示にかかる時間を確認します。その後のすべてのアプリケーションの起動（ウォームスタートアップ）がはるかに高速な場合、コールドスタートアップの問題はI/Oによって発生する可能性が最も高いです。

アプリケーションのコールドスタートアップの問題がI/Oに関連していない場合、アプリケーションが長時間の初期化や計算を実行したり、イベントが完了するのを待ったり、起動時にJITコンパイルを多く必要とする可能性があります。以下のセクションでは、これらの状況のいくつかをより詳細に説明します。

最適化モジュールのロード、アプリケーションの負荷をモジュールを決定するために、このようなプロセスエクスプローラ（Procexp.exe）とTlist.exeなど

のツールを使用して。コマンドTlist <pid>には、プロセスによってロードされたすべてのモジュールが表示されます。

たとえば、Webに接続しておらず、System.Web.dllが読み込まれている場合は、アプリケーションにこのアセンブリを参照するモジュールがあります。参照が必要であることを確認してください。

アプリケーションに複数のモジュールがある場合は、それらを1つのモジュールにマージします。このアプローチでは、CLRのアセンブリ・ロードのオーバーヘッドが少なくてすみます。アセンブリの数が少なければ、CLRの状態も少なくなります。

延期初期化操作

アプリケーションのメインウィンドウがレンダリングされるまで初期化コードを延期検討。

初期化がクラスコンストラクタ内で実行され、初期化コードが他のクラスを参照すると、多くのクラスコンストラクタが実行されるカスケード効果が発生する可能性があることに注意してください。

避けアプリケーション環境設定

は、アプリケーション構成を避けることを検討してください。たとえば、アプリケーションの構成要件が単純で、起動時間の目標が厳密である場合、レジストリエントリまたは単純なINIファイルは、より高速な起動方法です。アセンブリがグローバルアセンブリキャッシュ（GAC）、厳密な名前付きアセンブリのハッシュ検証によっておよびネイティブイメージのための場合NGENイメージの検証による遅延があるにインストールされていない場合

GAC

を活用そのアセンブリはコンピュータで使用できます。 GACにインストールされているすべてのアセンブリでは、厳密な名前の検証はスキップされます。詳細については、Gacutil.exe (Global Assembly Cache Tool)を参照してください。

使用Ngen.exe

アプリケーションにネイティブイメージジェネレータ（Ngen.exe）を使用して考えてみましょう。 Ngen.exeを使用すると、Ngen.exeによって生成されたネイティブイメージがMSILイメージよりも大きくなる可能性があるため、CPU使用量を増やすとディスクアクセスが増えます。

ウォームスタートアップ時間を短縮するには、Ngen.exeをアプリケーションで使用する必要があります。これは、アプリケーションコードのJITコンパイルのCPUコストを回避するためです。

いくつかのコールドスタートアップシナリオでは、Ngen.exeを使用すると便利です。これは、JITコンパイラ（mscorjit.dll）を読み込む必要がないためです。

NgenモジュールとJITモジュールの両方を持つことは、最悪の影響を及ぼします。これは、mscorjit.dllをロードする必要があり、JITコンパイラがコードで動作する場合、JITコンパイラがアセンブリのメタデータを読み取るときに、Ngenイメージの多くのページにアクセスする必要があるからです。

NGENとClickOnceの

あなたもロード時間の違いを作ることができ、アプリケーションを展開することを計画方法。 ClickOnceアプリケーションの配備はNgenをサポートしていません。アプリケーションにNgen.exeを使用する場合は、Windowsインストーラーなどの別の展開メカニズムを使用する必要があります。

詳細については、Ngen.exe (Native Image Generator)を参照してください。あなたはNgen.exeを使用している場合

リベースとDLLアドレスの衝突

は、ネイティブイメージがメモリにロードされたときにリベースが発生する可能性があることに注意してください。そのアドレス範囲がすでに割り当てられているため、DLLが優先ベースアドレスでロードされていない場合、Windowsローダーはそれを別のアドレスにロードします。これは時間のかかる操作になります。

仮想アドレスダンプ（Vadump.exe）ツールを使用して、すべてのページがプライベートであるモジュールがあるかどうかを確認できます。この場合、モジュールは別のアドレスにリベースされている可能性があります。したがって、そのページは共有できません。

ベースアドレスを設定する方法の詳細については、Ngen.exe (Native Image Generator)を参照してください。

最適化のAuthenticode

Authenticodeの検証は、起動時に追加されます。 Authenticode署名付きアセンブリは、証明機関（CA）で検証する必要があります。この確認は、現在の証明書失効リストをダウンロードするためにネットワークに何回か接続する必要があるため、時間がかかる可能性があります。また、信頼されたルートへのパスに有効な証明書の完全なチェーンが存在することを確認します。これは、アセンブリがロードされている間、数秒間の遅延につながります。

クライアントコンピュータにCA証明書をインストールするか、可能であればAuthenticodeを使用しないでください。申請書にパブリッシャーの証拠が必要ないことが分かっている場合は、署名検証の費用を支払う必要はありません。

.NET Framework   3.5以降では、Authenticode検証をバイパスする構成オプションがあります。これを行うには、app.exe.configファイルに次の設定を追加します。

<configuration> 
<runtime> 
    <generatePublisherEvidence enabled="false"/> 
    </runtime> 
</configuration> 

パフォーマンスを比較Windows Vistaの

にWindows Vistaのメモリマネージャは、SuperFetchはと呼ばれる技術を持っています。 SuperFetchは、特定のユーザーのための最適なメモリー内容を決定するために、時間の経過とともにメモリー使用パターンを分析します。いつでもそのコンテンツを維持するために継続的に機能します。

このアプローチは、Windows XPで使用されるプリフェッチ手法とは異なり、使用パターンを分析せずにデータをメモリにプリロードします。時間の経過とともに、ユーザーがWindows Vistaで頻繁にWPFアプリケーションを使用すると、アプリケーションのコールドスタートアップ時間が向上する可能性があります。

使用のAppDomainが効率的に

可能な場合は、ドメイン中立コード領域への負荷アセンブリは1つが存在する場合、ネイティブイメージは、アプリケーションで作成されたすべてのAppDomainで使用されていることを確認します。

最高のパフォーマンスを得るには、クロスドメインコールを減らして効率的なドメイン間通信を実施します。可能な場合は、引数なしで、またはプリミティブ型の引数で呼び出しを使用します。

はResourceManagerのためのニュートラルカルチャを指定するNeutralResourcesLanguageAttributeを使用しNeutralResourcesLanguage属性に

を使用してください。このアプローチは、失敗したアセンブリ参照を回避します。

は、あなたがシリアル化を使用する必要がある場合はシリアライズ

ためにBinaryFormatterクラスを使用して、BinaryFormatterクラスの代わりXmlSerializerクラスを使用します。 BinaryFormatterクラスは、mscorlib.dllアセンブリのBCL（Base Class Library）に実装されています。 XmlSerializerはSystem.Xml.dllアセンブリに実装されています。これは追加のDLLを読み込むためのものです。

XmlSerializerクラスを使用する必要がある場合は、シリアライゼーションアセンブリを事前に生成すると、パフォーマンスが向上します。

アプリケーションがClickOnceのを使用している場合は設定のClickOnceは、アプリケーションの起動後にアップデートの配布サイトをチェックするのClickOnceを設定することで、起動時にネットワークアクセスを防ぐため、スタートアップ後アップデートの

をチェックします。

XAMLブラウザーアプリケーション（XBAP）モデルを使用する場合は、XBAPが既にClickOnceキャッシュに存在する場合でも、ClickOnceが展開サイトで更新を確認することに注意してください。詳細については、ClickOnce Security and Deploymentを参照してください。

設定PresentationFontCacheサービスは再起動がPresentationFontCacheサービスです後に実行するために自動的に

最初のWPFアプリケーションを起動します。サービスはシステムフォントをキャッシュし、フォントアクセスを改善し、全体のパフォーマンスを向上させます。サービスの開始にはオーバーヘッドがあり、制御されている環境によっては、システムが再起動したときにサービスが自動的に開始されるように設定することを検討してください。

設定データの代わりに、メインウィンドウの宣言DataContextを設定OnActivated方法でプログラムを設定することを検討するためにXAMLを使用してのプログラム

を結合。

Answer 2

Framework 3.51ではなく3.5または3.0を使用すると、WPFアプリケーションの起動時間を大幅に短縮できます。 3.51は本当に改善点です。

Answer 3

スチュアートがリンクしている優れた記事の中で、XmlSerializerのトリックが最も役立ったのは何ですか。それは本当にかなりの時間を削った。さらに、あなたのHDのデフラグを過小評価しないでください:-)

Answer 4

私が今まで見たWPFスタートアップのパフォーマンスを改善するための最も有用なアドバイスは、in this other questionです：すべてのフレームワークフォルダに "ngen   update"を実行してください。

マイクロソフトでは、ngenキャッシュを最新の状態に保つことができないため、アプリケーションの起動時に.NETフレームワークの半分がほとんど再コンパイルされないようです。

信じがたいですが、そうであるようです。

Answer 5

これは古いスレッドですが、Win10システムでWPFアプリケーションの起動時のパフォーマンスの問題を修正しようとしている中で、ここで何度か終了しています。このシステム上のすべてのWPFアプリケーションの起動時間はわずか5秒で、わずか数ミリ秒に短縮されます。 nVidia "3d Vision"ドライバを削除します。私はGeForce GTX 650カードを持っていて、 "3d Vision"ドライバは役に立たないと思われるので、それを取り除くことは私にとって問題ではありません。 VisualStudio2015のパフォーマンス分析ツールは、nVidiaドライバであるnvapi64.dllを通じた呼び出しの後、ほとんどすべての5秒の起動時間がIDLEに費やされたことを示しました。ワオ。