• 發行項

本文章是由機器翻譯。

CLR

.NET 4.5 的效能改進概觀

Ashwin Kamath

 

本文討論了 Microsoft 的預發佈版本。NET 框架 4.5。所有相關的資訊如有更改。

微軟。NET 框架的團隊，我們一向明白提高性能是至少價值，如添加新的運行時功能和圖書館的 Api 的開發者。。NET 框架 4.5 包括大量投資性能，所有的應用程式方案中受益。此外，因為。NET 4.5 是更新。NET 4，甚至你。NET 4 應用程式可以享受許多現有的性能改進。NET 4 的功能。

使開發人員能夠提供令人滿意的應用經驗的時候啟動時間 (看到 msdn.microsoft.com/magazine/cc337892)，記憶體使用情況 （請參閱 msdn.microsoft.com/magazine/dd882521)，輸送量和回應真的重要。我們對改善這些度量標準，為不同的應用場景中，設定目標，然後我們設計滿足或超過他們的更改。在本文中，我將提供一些主要性能的改進，我們在取得的高級概述。NET 框架 4.5。

CLR

在此版本中，我們著重于：利用多個處理器核心，以提高性能，減少在垃圾回收器的滯後時間，提高代碼品質的本機映射。以下是一些關鍵性能改進的功能。

多核只是中-即時 (JIT) 我們不斷監察低級硬體方面取得進步，並與晶片供應商合作，以達到最佳的硬體輔助性能。特別是，我們已經有多核晶片在我們性能實驗室中因為他們可用，並進行了適當更改來利用此特定硬體更改 ； 然而，這些更改受益起初的極少數客戶。

在這一點上，幾乎每一台電腦有至少兩個內核，這樣的新功能，需要多個核心立即大致有用。在早期的發展。網 4.5，我們出發來確定是否合理使用多個處理器核心共用的 JIT 編譯任務 — — 專門為應用程式啟動時的一部分 — — 加快整體的體驗。作為調查的一部分，我們發現足夠託管應用程式與 JIT 編譯的方法，使投資值得多個最小閾值。

該功能的工作原理 JIT 編譯方法可能的多核機器上將上另一個核心，並行運行的後臺執行緒上執行。在理想的情況下，第二個核心快速獲取提前的主線執行應用程式，因此大多數方法是 JIT 編譯在需要的時候。為了知道要編譯的方法，該功能會生成跟蹤的方法所執行的設定檔資料，然後由指導此設定檔資料上以後運行。此生成的設定檔資料的要求是，您與此功能進行交互的主要方式。

最少增加代碼後，您可以使用此功能，則運行庫的顯著改進的用戶端應用程式和 Web 網站的啟動時間。特別是，您需要使兩個靜態方法簡單調用 ProfileOptimization 的類、 System.Runtime 命名空間中。請參閱 MSDN 文檔的詳細資訊。請注意預設情況下啟用此功能的 ASP。NET 4.5 應用程式和 Silverlight 5 應用程式。

優化的本機映射，幾個版本，我們使您預編譯代碼，以通過調用本機映射生成 (NGen) 工具的本機映射。隨之而來的本機映射通常會導致速度大大加快應用程式啟動時不親眼看到的 JIT 編譯。在此版本中，我們引入一個稱為管理設定檔引導優化 （MPGO），甚至更高的性能的本機映射的佈局優化的補充工具。MPGO 使用配置優化的技術，在概念 JIT 前面所述的多核非常相似。這款應用程式的設定檔資料包括代表方案或組的情景，它們可以用來重新排序的方法和其他在啟動時所需的資料結構是協同定位在本機映射，從而縮短啟動時間並減少工作集 （應用程式的記憶體使用情況） 的一部分內人口稠密的本機映射的佈局。在我們自己的測試和經驗，我們通常看到一較大的託管應用程式 （例如，大型互動 GUI 應用程式），與 MPGO 的好處，我們建議這些方針很大程度上其使用。

MPGO 工具生成的中間語言 (IL) DLL 的設定檔資料，並將設定檔作為資源添加到 IL DLL。NGen 工具用於後性能分析，預編譯的 IL Dll，它執行額外由於存在的優化設定檔資料。圖 1 直觀顯示的流程。


圖 1 過程流使用 MPGO 工具

大型物件堆 (蕙) 分配器很多。淨開發商要求一個或逼壓實的蕙蕙碎片問題的解決方案。你可以閱讀更多有關如何蕙工作在 2008 年 6 月由貓膩斯蒂芬斯在 CLR 內而外列 msdn.microsoft.com/magazine/cc534993。若要總之，任何物件的大小為 85,000 位元組或更多獲取蕙上分配。目前，蕙不壓縮。壓縮陸恭蕙會消耗很多時間，因為垃圾回收器會有移動大型物件，因此，是一個昂貴的命題。獲取收集蕙上的物件，當他們離開生存該集合，這會導致碎片問題的物件之間的自由空間。

若要解釋位更，CLR 使自由清單的死亡的物件，從而能夠重用來滿足大型物件分配請求 ； 相鄰的死亡物件被製成一個免費的物件。最終一個程式可以最終情況凡這些可用記憶體碎片活大物件之間不是足夠大，以在蕙，作出進一步的物件分配和因為壓實不是一個選項，我們很快會遇到問題。這會導致應用程式不回應，最終會導致記憶體不足異常。

中。網 4.5 我們作了一些變動使有效使用的記憶體碎片在蕙議員，特別是有關我們管理自由清單的方式。所做的更改應用到工作站和伺服器垃圾回收 (GC)。請注意這並不改變蕙物件的 85,000 位元組限制。

背景 GC 伺服器中。我們啟用網 4 背景 GC 氣相色譜工作站。自那時以來，我們已經看到機端上堆的更大的頻率大小從幾 gb 千百萬位元組數萬該範圍。甚至優化並行署長像我們這樣可以採取秒鐘來收集這類大的堆，從而阻止應用程式執行緒秒。GC 伺服器的背景介紹併發收藏到我們伺服器收集器的支援。它在繼續保持應用程式的高輸送量的同時最小化長時間阻塞的集合。

如果您使用的 GC 伺服器，您不需要執行任何操作即可利用此新功能 ； GC 伺服器後臺會自動發生。高級別背景 GC 特徵是相同的用戶端和伺服器 GC：

  • 只有充分 GC （第 2 代） 可以在後臺發生。
  • 氣相色譜法背景不會緊湊。
  • 前臺 GC (代 0 1 代 GC) 可以在背景 GC 期間發生。GC 伺服器是專用的伺服器 GC 執行緒上進行的。
  • 完全阻塞的 GC 恰好也在 GC 專用的伺服器的執行緒上。

非同步程式設計

一種新的非同步程式設計模型引入為 Visual Studio 非同步 CTP 的一部分，目前的一個重要部分。NET 4.5。這些語言中的新功能。NET 4.5 使您能夠高效地編寫非同步代碼。C# 和 Visual Basic 稱為"非同步"和"等待"中的兩個新語言關鍵字使這種新模式。.NET 4.5 也已更新為支援非同步應用程式使用這些新的關鍵字。

在 MSDN 上的 Visual Studio 非同步程式設計門戶 （msdn.microsoft.com/vstudio/async) 是一種偉大的資源樣品、 白皮書和新的語言功能和支援的談判。

平行計算的圖書館

平行計算庫 (PCLs) 中的，提出了一些改進。加強現有的 Api 網 4.5。

更快更輕量化任務的 System.Threading.Tasks.Task 和 <TResult> 的任務 類是使用較少的記憶體，並在關鍵方案中更快地執行優化。具體來說，有關創建任務和計畫延續案件看見最高達 60%的性能改進。

更多 PLINQ 查詢執行並行 PLINQ 中回落到循序執行時，它認為它不會更加的並行查詢的危害 (使事情速度較慢）。這些決定是有根據的推測，並不總是完美的、 和中。NET 4.5，PLINQ 將承認它成功可以並行化的查詢更多類。

< TKey、 TValue > System.Collections.Concurrent.ConcurrentDictionary 提出的調整更快併發集合 A 一些 要使它更快的某些情形。

這些更改的詳細資訊，請檢查出在平行計算平臺團隊博客 blogs.msdn.com/b/pfxteam。

ADO。網

客戶利用 SQL Server 2008 稀疏列功能尤其常見空位壓縮行支援 Null 資料。客戶利用稀疏列功能可能會產生含有大量的空值的列的結果集。這種情況下，引入行空-位-壓縮 （SQLNBCROW 權杖或，簡單地說，NBCROW）。這減少了從具有大量列的伺服器發送的壓縮到一個位元遮罩的 NULL 值的多個列的結果集行所使用的空間。這大大有助於資料表格格式資料流程 (TDS) 協定壓縮的資料在資料中有很多的 nulled 的列。

Entity Framework

LINQ 查詢時您編寫 LINQ 實體查詢到今天，走過生成的 C# / 視覺的運算式目錄樹的實體框架自動編譯基本編譯器和轉換 （或編譯） 成 SQL，如中所示， 圖 2。


圖 2 LINQ to 實體查詢轉換成 SQL

編譯成 SQL 運算式目錄樹涉及一些開銷，但是，特別是對於更複雜的查詢。在以前版本的實體框架，如果你想要避免不得不支付這種性能下降，每次執行 LINQ 查詢，您必須使用 CompiledQuery 類。

這個新版本的實體框架支援稱為 Auto-Compiled LINQ 查詢的新功能。現在每個 LINQ to 您自動執行的實體查詢獲取編譯，且放置在實體框架的查詢計畫快取記憶體。每個額外的時間，運行查詢，實體框架會發現它在其查詢緩存和不必再去通過整個編譯過程。你可以閱讀更多關於它在 bit.ly/iCaM2b。

Windows 通訊基礎和基礎工作流

Windows 通信基礎 (WCF) 和 Windows 工作流的基礎 (WF) 團隊也如做一堆在此版本中，性能改進：

  • TCP 啟動可擴展性改進：客戶報告了 TCP 啟動的問題，許多併發使用者發送時不斷重新連接的請求，共用服務的 TCP 埠並沒有很好地擴展。此問題已修復中。NET 4.5。
  • 內置 GZip 壓縮支援 WCF HTTP/TCP 的：這種新的壓縮，我們預期達 5 x 壓縮率。
  • 當記憶體使用率很高的 WCF 回收主機：時的記憶體使用率很高 （可配置的旋鈕），我們使用最近最少使用 （LRU） 邏輯回收 WCF 服務。
  • HTTP 非同步流 WCF 的支援：我們實施了這項功能中。NET 4.5，實現相同的同步流，但輸送量多更好的可擴展性。
  • WCF TCP 的一代 0 碎片改善。
  • 大型物件 WCF 的的優化的 BufferManager：對於大型物件，以避免高第 2 代 GC 成本更好的緩衝集區已得到執行。
  • 白表驗證運算式緩存的改進：我們預計達 3 x 改進為核心方案的載入 WF 和執行它。
  • 實現 WCF/WF 端到端事件跟蹤的 Windows (ETW)：雖然這不是性能改進功能，它可以説明客戶性能的調查工作。

您可以在工作流的團隊博客上找到更多詳細資訊 blogs.msdn.com/b/workflowteam 和 MSDN 庫在文章中 bit.ly/n5VCtU。

ASP。網

提高網站密度 （還定義為每個網站的記憶體"消費"） 和冷開機時間的網站共用主機的情況下已經 ASP 的兩個關鍵的性能目標。網隊。NET 4.5。

在共用宿主方案中，很多網站共用同一台機器。在這種環境中交通是通常較低。一些宿主公司顯示出每秒請求低於 1 rps，偶爾峰的 2 退休保障計畫或更多的時間，大部分提供的資料。這意味著許多工作進程可能會死當他們空閒很長時間 （預設情況下，IIS 7 和以後的 20 分鐘）。因此啟動時間變得非常重要。在 ASP。網，這是一個 Web 網站接收的請求，並回應，當工作進程下降了與 Web 網站已編譯時花費的時間。

我們在此版本中要縮短啟動時間共用宿主方案實施了幾個功能。使用的功能是：

  • Bin 元件限定 (共用常見元件):ASP。淨的卷影副本功能可以使用的程式集的應用程式定義域中進行更新，而不卸載該應用程式定義域 （必要因為 CLR 鎖定正在使用的程式集）。這通過將應用程式程式集複製到一個單獨的位置 （預設 CLR 確定位置或使用者指定的一個），並從該位置載入的程式集。這允許要卷影複製被鎖定的同時更新的原始程式集。ASP。網路打開此功能在預設情況下 Bin 資料夾的程式集，使 Dll 可以繼續網站啟動和運行的同時更新。
  • ASP。網承認 Bin 資料夾中的 Web 網站作為一個特殊的資料夾為自訂的 ASP 編譯的程式集 (Dll)。淨控制項、 元件或需要在 ASP 中引用的其他代碼。網中的應用及共用跨網站的不同頁面。獲取自動引用 Bin 資料夾中的已編譯器的集到處都在 Web 應用程式中。ASP。網還檢測特定的 DLL 的最新版本的 Web 網站在 Bin 資料夾中使用。預先包裝的應用程式要使用 ASP 的目的。淨網站通常安裝到 bin 資料夾，而不是全域組件快取中。
  • ASP。NET 和 CLR 團隊發現當很多網站駐留在同一台伺服器上，並使用相同的應用程式，許多這些卷影副本的 Dll 往往會完全一樣。如從磁片中讀取這些檔並將其載入到記憶體中，這會導致增加啟動時間和記憶體消耗的許多冗余負載。使用符號連結為 CLR 遵循和執行情況，我們創造了­因為這識別常見的檔並拘留他們在特殊的位置 （哪些符號連結將點）。ASP。網自動配置卷影複製為上 Bin Dll。共用託管商們現在可以設置到 ASP 根據他們的機器。淨效益最大的性能準則。
  • 多核的 JIT：請參閱前面的"CLR"部分中的相關的資訊。ASP。淨團隊使用多核的 JIT 功能提高啟動時間傳播個處理器核心的 JIT 編譯。這是預設情況下，ASP 中啟用。淨，所以您可以利用此功能無任何額外的工作。您可以禁用它在 web.config 檔中使用下列設置：
<configuration>
<!-- ...
-->
<system.web>
<compilation profileGuidedOptimizations="None" />
<!-- ...
-->
  • Prefetcher：在 Windows 中的 prefetcher 技術是非常有效地減少磁片讀取分頁在應用程式啟動過程中的成本。 Prefetcher 現在啟用 （但不是在預設情況下） 在 Windows 伺服器上也是的。 要啟用 Prefetcher 高密度的虛擬主機，請在命令列運行下麵的命令集：
sc config sysmain start=auto
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters" /v EnablePrefetcher /t REG_DWORD /d 2 /f
reg add "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Prefetcher" /v MaxPrefetchFiles /t REG_DWORD /d 8192 /f
net start sysmain
  • 然後，您可以更新 web.config 檔，以在 ASP 中使用它。網路：
<configuration>
<!-- ...
-->
<system.web>
<compilation enablePrefetchOptimization
  ="true" />
<!-- ...
-->
  • 調 GC 的高密度虛擬主機：氣相色譜法可以影響網站的記憶體消耗，但是它可以進行調整，以便更好的性能。 您可以調整或配置為更好的 CPU 性能 （降低頻率的集合） 或更低的記憶體消耗的 GC (即，更頻繁要越早釋放記憶體的集合）。 要啟用優化的 GC，您可以在每個網站以實現更小的記憶體消耗 （工作集） 選擇在 Windows\Microsoft\v4.0.30319 資料夾中的 aspnet.config 檔中的 HighDensityWebHosting 設置：
<configuration>
<!-- ...
-->
<runtime>
<performanceScenario
  value="HighDensityWebHosting" />
  <!-- ...
-->

ASP 的更多詳細資訊。淨的性能改進，可以在"快速入門的下一版本的 ASP。NET"白皮書在 bit.ly/A66I7R。

想要的回饋

此處顯示的清單中並不是詳盡無遺。 有更多輕微更改以提高性能保持的範圍限制為主要功能的這篇文章已被略去。 除此之外，。NET 框架性能團隊也一直在忙工作的特定的 Windows 8 託管地鐵樣式的應用程式的性能改進。 一旦您下載並試用。NET 框架 4.5 和 Visual Studio 11 beta 版的 Windows 8，請讓我們知道是否你有任何的回饋或建議發佈的未來。

術語表

**共用主機：**也稱為"共用的 Web 宿主，"高密度虛擬主機使數百名 — — 如果不是數千 — — 在同一伺服器上運行的 Web 網站。 通過共用的硬體成本，每個網站可以保持較低的成本。 這種技術大大降低了進入壁壘，Web 網站所有者的。

**冷開機：**冷開機時是在您的應用程式已經不存在記憶體中時啟動所需的時間。 你可以體驗冷開機時的啟動應用程式後重新開機系統。 對於大型應用程式，冷開機時可能需要幾秒，因為需要的頁面 （代碼、 靜態資料、 註冊表等等） 不是目前在記憶體中，並須昂貴的磁片訪問帶到記憶體中的頁面。

**溫暖啟動：**溫暖的啟動是啟動已經存在於記憶體的應用程式所需的時間。 例如，如果應用程式已啟動較早前的幾秒鐘，它是可能的大部分頁面已載入到記憶體中，作業系統將重用它們，節省昂貴的磁片存取時間。 這就是為什麼是啟動第二次運行時就更快的應用程式 （或為什麼第二。網路應用程式啟動快于第一、 因為部分。網將已載入在記憶體中）。

**本機映射生成或 NGen：**是指機器代碼之前，執行時間到中間語言 (IL) 的可執行檔的預編譯的過程。 這將導致兩個主要的性能優勢。 首先，它通過避免在運行時編譯的代碼需減少了應用程式啟動時間。 第二，它的內碼表的多個進程共用，從而提高了記憶體使用情況。 也是一種工具，NGen.exe，創建本機映射，並將它們安裝到本地電腦上的圖像本機快取記憶體 （NIC）。 當他們可用，則運行庫將載入本機映射。

**設定檔為指導優化：**已證實引導設定檔優化提高啟動和本機和託管應用程式的執行時間。 Windows 提供了工具套件和基礎設施，以執行設定檔引導優化對於本機程式集，而 CLR 提供的工具集和基礎設施，以執行配置優化為託管程式集 （稱為託管配置優化或 MPGO）。 這些技術是許多團隊在 Microsoft 內部用於改善其應用程式的性能。 例如，CLR 執行本機程式集 （c + + 設定檔引導優化） 和託管程式集 （使用 MPGO） 的引導下的設定檔優化。

垃圾回收器：。淨運行庫支援自動記憶體管理。 它跟蹤託管程式所作的每個記憶體分配，並定期調用，不再查找中使用的記憶體，並將它重新用於新的分配的垃圾回收器。 垃圾回收器執行重要優化是不搜索整個堆每次，而是進行分區堆成三代 （第 0、 1 代和第 2 代）。 垃圾回收器的詳細資訊，請閱讀 2009 年 6 月在 CLR 內而外列 msdn.microsoft.com/magazine/dd882521。

**壓縮：**在垃圾回收，堆到達那裡它充分分散，一個國家時，垃圾回收器將壓縮堆通過移動靠近對方的活動物件。 壓縮堆的首要目標是記憶體的，使較大塊可用於分配更多的物件。

Ashwin Kamath 是上的 CLR 團隊的專案經理。淨，開車來的性能和可靠性的功能。NET 框架 4.5。目前，他正在對 Windows Phone 開發平臺的診斷功能。

多虧了以下的技術專家審查這篇文章：Surupa Biswas， Eric Dettinger， Wenlong Dong， Layla Driscoll， Dave Hiniker， Piyush Joshi， Ashok Kamath， Richard Lander， Vance Morrison， Subramanian Ramaswamy， Jose Reyes， Danny Shih 和 Bill Wert