等待應用程式啟動是讓使用者最感到挫折的體驗之一。專注優化客戶端應用程式啟動效能，不僅能強化客戶首次印象，更能讓他們對你的產品留下深刻好感。鑑於啟動效能對使用者至關重要，深入研究其影響因子、避開常見錯誤，絕對值得投入資源。
應用程式啟動分為冷啟動與熱啟動。在 Managed 環境中，冷啟動指 .NET Framework 系統組件與應用程式碼均不在記憶體中，必須從磁碟讀取；熱啟動則是後續啟動，或因先前其他 Managed 應用程式已載入系統碼而大部分程式碼已駐留記憶體的情況。
絕大多數情況下，冷啟動受限於 I/O。啟動耗時 = 作業系統從磁碟提取碼的時間 + JIT 編譯 IL 碼等處理時間 + 啟動路徑上其他初始化時間。因處理通常非瓶頸，初始優化目標應為減少載入碼量以降低磁碟存取。
應用程式碼撰寫方式對冷啟動影響深遠，必須釐清：啟動時是否開啟其他檔案？是否啟動爭奪 I/O 資源的其他進程？
傳統 CPU 分析器（無論檢測式或取樣式）對調查冷啟動幫助有限。檢測式分析器將等待 I/O 時間回報為封鎖時間，但即使歸因特定呼叫堆疊，封鎖時間也僅計算一次，後續磁碟 I/O 被忽略，導致實際 I/O 時間被低估。取樣式分析器追蹤 CPU 使用率而非 I/O，報告中甚至不會記錄 I/O 總耗時，資訊極具誤導性。
圖 1：冷啟動中磁碟讀取時間佔比遠高於 CPU 時間
連續兩次啟動應用程式即可體會差異：首次啟動顯著較慢，第二次因程式碼已在記憶體中而大幅加速。執行理想冷啟動測試需重開機、確保啟動資料夾無 Managed 應用程式、無使用 Managed 碼的 Windows 服務運行，並停用 SuperFetch 服務（否則會預載程式碼造成較熱啟動）。關閉 SuperFetch 測量雖能精確衡量 I/O 成本，但不一定反映真實使用者體驗，切勿據此下結論。
可用兩個效能計數器觀察 I/O 影響：處理器時間百分比與磁碟讀取時間百分比。若 I/O 制約冷啟動，兩者差距極大。圖 1 中紅線（磁碟讀取）高於綠線（CPU），冷啟動時 CPU 使用率相對較低。
圖 2：熱啟動時間更短，CPU 成為瓶頸
熱啟動受限於 CPU，因碼已在記憶體，無額外 I/O，但需對碼執行 JIT 編譯。.NET Framework 不會在每次執行時保存 JIT 產生的原生碼。若熱啟動未明顯快於冷啟動，需找出佔用 CPU 週期的原因：可能是大量碼需 JIT，或應用程式執行複雜計算。
檢查 .NET CLR JIT 效能計數器「時間百分比」。若值不高（如啟動前幾秒超過 30%-40%），JIT 非主因，應用分析器找出佔用 CPU 的功能。注意：計數器僅在實際執行 JIT 時更新，對最後一個方法 JIT 後仍回報上一值，不會降為零。務必僅觀察啟動前幾秒，若計數器快速上升，表明 CPU 峰值源自 JIT 編譯器。
另需注意：使用者登入時載入的所有應用程式會與其他服務爭奪 I/O，導致啟動變慢。應盡量避免加入啟動群組（可用 AutoRuns 工具檢視並管理啟動項目）。
下一步是確認從磁碟載入了什麼，發現無意間載入的組件。最快方法是使用 VADump 工具（Windows Platform SDK 內建）。執行 VADump –sop <proc ID> 可生成報告，顯示各模組工作集貢獻。
關鍵提醒：VADump 僅顯示執行工具時載入記憶體的內容，可能漏掉極短暫駐留的模組，也不會顯示已分頁輸出至磁碼的部分。目標是檢視報告，確認列表中所有模組是否必要。例如應用程式未使用 XML 卻載入 System.Xml，即需調查原因。
若需確定載入特定組件的呼叫者，可在 Windows 偵錯工具 (windbg) 中使用 sxe ld:<dll name> 指令，使偵錯器在載入指定 DLL 時中斷，再檢查呼叫堆疊。此調查極易被忽視卻至關重要。
解決啟動時載入不必要組件後（可延遲非必要初始化），下一步是減少從系統組件載入的碼量。可惜目前無工具能確定使用系統 API 時具體提取了多少碼。若有此工具，開發人員可選擇需載入較少碼的 API，並配合檢測式分析器（如 Visual Studio 效能工具）了解 API 頁面成本。
分析資料中應避免涉及大型呼叫樹（深層巢狀呼叫意味著每個方法調用的碼皆從磁碟提取，代價高昂）的系統呼叫 API。若能透過呼叫無深層呼叫樹的 API 達同樣功能，可節省時間。這非科學方法，但通常較大呼叫樹意味著需載入更多碼。
應用程式啟動時可能顯式或隱式啟動其他進程。Windbg 的 -o 選項可輕鬆識別子進程。典型隱式啟動案例：使用 XML 序列化且未預編譯序列化類（使用 Sgen 工具），將啟動 C# 編譯器編譯它們。啟動額外進程通常代價高昂，嚴重影響啟動效能。
原生映像產生器 (NGen) 總有助於改善熱啟動（避免 JIT）。若無需載入 mscorjit.dll，NGen 對冷啟動也有幫助（所有碼預編譯）。但若僅有一個模組缺少原生映像，仍會載入 mscorjit.dll，不僅執行 JIT 佔用 CPU，JIT 編譯器讀取中繼資料還會觸及 NGen 映像許多頁面，反而惡化啟動。
建議移除可能導致啟動期間執行 JIT 的所有碼。是否採用 NGen 需在使用與不使用原生映射測量冷啟動後決定，因實際優勢取決於應用程式碼與大小，即使啟動無 JIT 也無法保證顯著改善。
判斷是否及何時執行 JIT 的一個方法是使用 Managed 偵錯助理 (MDA)。設定環境變數 COMPLUS_MDA=JitCompilationStart，執行 JIT 時應用程式會進入偵錯器或列印偵錯資訊。亦可透過登錄或 .config 檔啟用 MDA。
確保 NGen 有利冷啟動的三大前提：
使用 signcode 工具對組件執行 Authenticode 簽名。Authenticode 驗證對啟動恆有負面影響，因簽名組件需由憑證授權單位 (CA) 驗證，若 CA 未本機安裝則需網路存取，代價高昂。理想做法是避免 Authenticode 簽名，改用強名稱簽名。若無法避免，.NET Framework 3.5 提供設定選項跳過驗證：
<configuration>
<runtime>
<generatePublisherEvidence enabled="false"/>
</runtime>
</configuration>
但在必須 Authenticode 簽名時，在客戶端電腦安裝 CA 憑證仍可節省大部分驗證時間。
獲得良好冷啟動效能的最佳實務：讓啟動時執行的碼極度精簡。意即延遲非必要初始化、檢查所有參考確保不會過早載入、盡量使用無需載入大量碼的類別與方法。核心目標是減少磁碟存取。
即將推出的 Windows Server 2008 SDK 包含新工具 Xperf，運用 Windows 事件追蹤 (ETW) 追蹤載入模組、內容切換等事件，有助精確掌握啟動期間發生的操作，收集極精確的啟動時間指標。「啟動效能資源」側欄含多項實用參考。
