本文章是由機器翻譯。

深究 CLR

在.NET Framework 3.5 SP1 的 CLR 最佳化

Surupa Biswas

內容

啟動效能改良
JIT 最佳化
NGen 和 ASLR
.NET Framework 3.5 用戶端的設定檔
向上換行

一個特殊的工作量會進入於 8 月 2008 發行的.NET Framework 3.5 SP1 的 Microsoft.NET Framework 的核心。 這裡，我將提供深入資訊我們 CLR 小組 Common Language Runtime (CLR) 所作的變更 」 和 「，改進您可以預期只執行您現有的 CLR 2.0 應用程式，針對這個最新的 Service Pack。 我們努力的大部分被中央改善效能、 安全性和應用程式的目標.NET 平台的部署。

之前請探究詳細資料，請注意您可以下載， .NET Framework 3.5 SP1從 Microsoft 下載中心 」。 也是可透過 Windows Update。 而且，看 [圖 1 。 它回答 perennial 問題： 這是內部的.，.NET Framework 版本的 CLR 版本嗎？

啟動效能改良

改善啟動效能 — 在特定的 Managed 應用程式的冷啟動時間 (已在.NET Framework 3.5 SP1 的主要焦點。

受管理的組件，在.NET Framework 是主要是會透過 NGen 先行編譯 (」 NGen 效能優點「)，且程式碼和 NGen 影像資料的版面配置使用在 Framework 的應用程式的啟動效能增強式的影響。 會將特別，因為初次啟動時間通常繫結的頁面的影像，需要從磁碟讀取數，任何努力減少轉譯為更好的套件的努力影像，因此只有一小部分其頁面會讀取在啟動期間。

該效果，CLR 會使用一個設定檔-驅動引擎最佳化的.NET Framework 中組件的 NGen 影像的版面配置。 藉由執行案例，我們認為是代表我們架構的使用量的並將它正在建置時再包含在對應的組件中做為資源收集在設定檔的資料。 NGen，期間如果這類資源位於的組件用它來 Pack 熱門 」 程式碼和資料 (那些訓練案例在執行時所存取) 一起，藉此移到 「 冷的程式碼和資料其自己的區段，在影像中。

此外，.NET Framework 3.5 SP1 所包含的數個改良以我們熱 / 冷分割基礎結構，依次改善，NGen 影像的區域性的。 Basic 特別，在包含不同類型的控制流程的方法中的區塊 (例如切換陳述式或無條件的分支 — 是立即重新整理，更冷的區塊可以分割關閉並移至 NGen 影像的冷的部分。 我們也實作更好的演算法合併設定檔資料，從多個訓練案例 — 排定優先我們現在順序一起封裝 / 程式碼存取的資料集中給定的訓練的案例的最大數目。 最後，進一步增強的程式碼會執行一起 temporally 空間區域性，NGen 影像裡的可執行程式碼會分成 RunOnce、 RunMany 和 RunNever 區段。 我們的分析資料集合，並使用這些改良功能已針對同時在 32 位元和 64 位元平台。 這些的變更的結果發生在更高比的初次接觸訓練案例已重新執行受過訓練的.NET Framework 的上方時的頁數減少 50%(有時候明顯較)。

不幸的是，我們的設定檔資料收集 Framework 為仍然內部-僅的。 而這項工作的好處在啟動的應用程式的組件無法進一步的 NGen 啟動效能最佳化藉由使用我們的教育訓練的使用.NET Framework 程式庫的所有 Managed 應用程式架構。 我們希望讓這個架構有時候使用，所以敬請 ！

請注意，一個有點不相關的變更 (」 強式名稱，略過 」) 也解決我的文件稍早所述的另一個 NGen 相關問題 」 NGen 效能優點"即，時間會花驗證強式名稱簽章。

JIT 最佳化

有點切換齒輪，.NET Framework 3.5 SP1 也包含由 32 位元和 64 位元的 JIT 編譯器產生程式碼的品質的改進。 尤其，32-bit JIT 都可以立即內嵌方法呼叫，牽涉到傳遞、 傳回，或結構上作業。 才能這個的發行版本 32-bit JIT 只提供最多嘗試內嵌例如函式因為結構不是頂級的市民在 x86 JIT，降低到 byref 的指標，很早在編譯處理序中。 一旦發生這種情況不再能夠識別，結構 JIT，且無法執行的最佳標準化，例如複製傳用，基本型別上所執行的。

因此在下列範例中，JIT 編譯器無法判定它只需要傳播 a 到最後一個陳述式並而產生重複的複本的三個集合的程式碼 (b = 一個; c = b; d = c;)。

MyStruct a, b, c, d;
a = new MyStruct(1, 2);
b = a;
c = b;
d = c;
Console.WriteLine(d);

這項工作的目標會是因此允許的使用結構，並啟用後續最佳化，例如複製屬性的函式的內嵌。 採用，方法是選取符合特定的啟發學習法的結構 (例如，不超過四個欄位，欄位基本型別，或參照，等等)，升級，欄位中的的編譯器的內部區域變數，並利用事實上標準的最佳化已啟用基本型別 (Primitive Type) 和參照。 因此，變更升級的結構上的所有作業，以反映個別 」 欄位區域變數上的作業 在部落格上，可以是找到更多有關這詳細資料 JIT、 NGen，和其他 Managed 程式碼產生的專區 」. 之後調整 inliner heuristic，我們最後更好的程式碼品質與較低的 NGen 時間這項工作所以贏得-而就能獲勝。 請注意在 64 位元 JIT，inliner 不同，並不是 3.5 SP1 中大幅變更 ； 但是，我們已經做了許多改良後的應可在即將發行的.NET Framework 4.0 版本。

除了在 inliner 的工作在 3.5 SP1 的兩個 JIT 編譯器會立即更在傳播判斷提示 (什麼已知為 true) 接著會導致較佳的程式碼品質，因為的 eliminated null 檢查，之產生程式碼在 TypeOf 檢查，比較與常數、 變數，等之間的比較。

JIT 編譯器可以現在也 straighten 分支的預測是否比較可能要執行或不分公司。 因此，如果拍攝的分公司必須是較常見，比在秋天-透過程式碼路徑，會移動秋天-透過區塊進一步向下後區塊分支目標中,。 (條件的分支是也回復，當然)。 straightening 分支以這種方式有助於分支預測 (轉寄的分支通常是假設不沒有分支記錄時要採取) 並改善快取的位置。 以靜態方式預測一些分支的結果時 (例外的程式碼路徑會假設為不執行，執行個體，) 我們也會使用先前所述的設定檔資料的分支 straightening 目的。 這項工作本身導致大於比輸送量一些我們的 ASP.NET 的 10%改進 benchmarks。

雖然這並不是在 JIT 最佳化，以任何方式，我們沒有另一個重大的變更對 32 位元 JIT 編譯器，3.5 SP1 中。 為 Managed 呼叫的堆疊，EBP 鏈結可以現在會移位 (藉由在偵錯工具 」 或 「 分析工具)，判斷哪些函式所呼叫。 這只是表示 JIT 編譯器不再 EBP 使用可用的登錄，並改使用它以獨佔方式] 來儲存框架指標。 不過，請注意，它會推入，或顯示與每個函式呼叫 (以避免這樣的小方法的效能成本) 堆疊的 EBP JIT 編譯器不保證。 因此，查核 EBP 鏈結，現在讓您所叫用方法的順序的清單，但可以有從清單中遺漏的方法。 決定要產生 EBP 框架的因此它應該是相當容易判定指定瞭解該程式的完整清單呼叫圖形的方法時，我們沒有選擇保守的 heuristic 來。 不用說在偵錯模式中我們可以推入，或顯示每個函式呼叫 EBP 暫存器。 這項工作，主要動機是讓無法安全地使用我們 Managed 的堆疊查核行程 API 堆疊查核行程，Managed 應用程式正在執行時的核心模式分析工具。

NGen 和 ASLR

我們做了基礎結構會產生，寫出在 3.5 SP1 的 NGen 影像的一個重要 overhaul。 現在會更有效率、 使用較少的記憶體並會產生更精簡的影像。 這會導致 NGen 時間超過 100 (當相較於執行階段，使用舊的 NGen 基礎結構) 的改進] 與 [大約等運算式 Blend 某些大型的應用程式的冷啟動時間為 10%改進。 從資料結構會保存在 NGen 影像都是更精簡的事實上產生的影響啟動時間改進。 這項工作會提升.NET Framework 所設定以及好部分安裝時間後會花費的時間產生在 Framework 中組件的 NGen 影像。

開始這個 Service Pack 我們已經也選擇 NGen 影像到使用位址空間配置隨機 (ASLR) 安全性功能已加入至 Windows Vista (請參閱中的視窗 位址空間配置隨機在 Windows Vista 中"). ASLR 依賴虛擬位址空間，中的位置，有效地隨機載入 PE 影像的能力和因此能夠有效地修正位址上參照的影像本身。 Unmanaged 的影像與不同的是其包含直接參照只位置相同的影像中也包含在其他組件的 NGen 影像的程式碼 / 資料的直接參考所使用的 NGen 影像。 (請參閱 hardbinding 我先前的文件上一節 ＜ NGen 效能優點.") 輕鬆地設定邏輯的核心的修正程式無法處理這類的外部參考。 因此，更重要的工作，在.NET Framework 3.5 SP1 的其中一個包含變更的 NGen 影像，以消除這類的直接指標的使用，而放棄，我們會取得我們介紹 hardbinding 時，效能獲勝的格式。 間接參考 — 且 Managed 程式碼通常會包含許多這些 — 不昂貴只因為屬於涉及，但也因為它們需要修正設定預設的間接取值的其他層級。 (並在無法跨處理序共用的私密頁面中結果寫入至間接取值 (Indirection) 的儲存格)。 這些間接參考已 strewn 所有透過 NGen 影像 (並造成大量的私密的頁面)，因此上重建影像，例如，所有間接取值 (Indirection) 的儲存格是託管，一起，修補少的網頁，寫入在執行時間可能會導致大量的工作置中。 在結束時，效能降低的情況是可以測量在只有一些暖啟動和輸送量的案例，並甚至在這些情況下影響已最小。

其中一項 ASLR) 工作的副作用是，您不再需要擔心選擇您的 NGen 影像 (請參閱 noncolliding 基底位址 NGen 效能優點「) 時，Windows Vista 或較新的平台為目標。 (它是仍在 Windows XP 和舊版的平台問題但是)。 在其他的不相關的安全性變更以我們的 3.5 SP1 工具組建置的所有 Managed 應用程式是現在選擇成 資料執行防止 預設值。

.NET Framework 3.5 用戶端的設定檔

在.NET Framework 3.5 SP1 中，我們也嘗試其他已有與 Framework 的主要問題之一的位址 — 也就是，將它部署在使用者電腦上取得。 我們決定專注於提供一個 leaner Framework 套件的特定種類的所做的應用程式使用的 Framework 所提供的功能的子集。 因為這個套件的焦點，讓開發人員撰寫用戶端應用程式 — 主要 WPF-為基礎的應用程式 — 我們呼叫用戶端的設定檔。 請注意用戶端的設定檔會是 true，完整的.NET Framework 的子集。

簡介分割.在是更具挑戰性的工作，比規我們想原本畫為服務 Pack 發行版本的 Framework 的新方法。 尤其，我們已經有一個 「 水平切割 「 我們的產品的 ； 我們現在已介紹為 「 垂直切割 」。

這個有趣的案例相關安裝舊的架構，新的部分架構的頂端的領導人，反之亦然。 若要修剪組可能的情況下，我們做了下列的簡化：

• 只有在沒有安裝 (因為在 「 全新的 Windows XP 電腦上安裝 Framework 是最大的痛苦點) 的任何 CLR 2.0 Framework 的電腦上，可以安裝在用戶端設定檔。
• Framework 的舊版本無法安裝用戶端的設定檔的頂端 (因此 ASP.NET 堆疊包含在.NET Framework 2.0 無法安裝 3.5 SP1 用戶端設定檔中包含的新 CLR 的上方)-有就不是好讓我們來測試新舊 / 二進位碼檔案的所有產生的組合。

測試用戶端的設定檔的頂端，某些應用程式時，我們就會發生另一個有趣的狀況。 針對現有的.NET Framework 版本 (2.0/3.0/3.5) 某些應用程式似乎安裝並執行用戶端的設定檔的頂端，(因為它們都包含在同一個相容的 2.0 CLR)，並再時嘗試呼叫未併入用戶端的設定檔 API 的失敗! 做我們想這個問題的特定應用程式有沒有尋找安裝程式時，所記錄的 Framework 的安裝金鑰，請我們快速地發現這會影響所有 xcopy-部署應用程式以及。 結果，我們決定封鎖執行用戶端的設定檔的頂端，除非它們已明確地標示為能夠在子集合上執行的應用程式。 我們再變更執行階段，以確保非用戶端應用程式可以正常，無法立即，和使用診斷的錯誤訊息 (要求使用者安裝完整的.NET Framework 3.5 SP1) 時它們所執行的用戶端的設定檔。

A lot 目標用戶端設定檔功能，它所支援，以及等等都可以在中找到的子集的相關資訊，" .NET Framework 用戶端設定檔「 MSDN 上的文件。

向上換行

我想之前完成，說我們對大量的使用者要求在過去的 3.5 SP1，在執行階段所做的其他變更 — 能夠啟動受管理的應用程式從近端內部網路共用資料夾的完全信任而不需要以手動方式調整安全性設定。 這是.NET 安全性的部落格文章，進一步詳細說明 」 在 LocalIntranet 上的完全信任"，但似乎值得，以防您不知道，就是相關還，而是您所要長時間的項目。

本文只是被要讓您對在最新的 Service-Pack) 版本，.NET Framework 的 CLR，我們所做的變更的概念。 請注意沒有許多.NET Framework 以及 (概觀可以在中找到的其他部分所做的變更 Scott Guthrie 部落格內容. 在 conclusion，我希望您現在會期待有關嘗試使用這個版本，已經在進行中的年份。

如果您有任何問題] 或 [註解，不要)}> 我們的方式傳送。

您問題或意見寄至 clrinout@Microsoft.com.

Surupa Biswas 是 Microsoft CLR 團隊的程式管理員時。 她在執行階段的後端編譯器上運作，並主要是著重先行編譯的技術。