出處：
https://msdn.microsoft.com/zh-cn/magazine/dn973013(en-us).aspx

很多開發商花了絕大多數時間獲取應用程序才干正常發揮作用。更少的時間里專注于應用程序的性能。

盡管有了非常長一段時間分析工具在 Visual Studio 中的，他們是單獨的一組學習工具。很多開發者沒有花時間去學習和使用它們的時候會出現性能問題。

這篇文章將介紹 Visual Studio 2015 年新的診斷工具調試器窗體。

它還將描寫敘述怎樣使用它來分析性能作為定期調試工作流的一部分。

我會首先提供調試器的特性和功能的概述，然后對一個深潛演練。我會告訴你怎樣使用 PerfTips 來時間剖面的斷點和步驟之間的代碼、 怎樣使用診斷工具窗體來監視 CPU 和內存，以及怎樣拍攝快照來鉆深進內存增長和泄漏。

這篇文章中的功能都可用于調試最托管和本機項目。

微軟不斷地加入很多其它的項目類型的支持、 調試配置。

有關當前受支持的功能的最新信息，請查閱診斷工具窗體在博客的帖子 aka.ms/diagtoolswindow。在這個問題上單獨的一條將解釋怎樣在診斷工具窗體內使用 IntelliTrace （見”使用 IntelliTrace 對診斷問題更快，”） 來高速確定您的代碼中的 bug 的根源。

在調試時的性能
而不是執行一個完整的分析工具。你可能會採取一個或多個下面的步驟：

將代碼插入到應用程序 （比如 System.Diagnostics.Stop-手表） 來衡量各種點，依據須要來縮小熱路徑迭代加入秒表之間執行所需的多長時間。

逐句通過代碼。看看假設不論什么特別是單步執行”感覺慢”。
全部 （”暫停”） button在隨機點去感受怎樣遠的執行已取得進展的突破。

在某些圈子里這指作為”窮人的採樣”。
過度優化代碼沒有測量性能，有時通過在整個代碼庫應用一套性能最佳做法。
這些做法一般是不準確的不是用時間或兩者都好。

這就是為什么如今有性能工具在調試器中。他們將幫助您了解您的應用程序的性能，在正常調試過程中。

診斷工具窗體 您會注意到當 Visual Studio 2015 年調試代碼的新的診斷工具窗體中將會出現。如中所看到的的主要區別在于 圖 1。這些診斷工具在兩個相互補充的方式呈現信息。他們將圖形加入到時間軸中窗體的上半。并提供具體的信息選項卡中的底部。

圖 1 在 Visual Studio 2015 年新的診斷工具窗體

在 Visual Studio 到 2015 年，您將看到在診斷工具窗體中的三個工具：調試器 （包含 IntelliTrace）、 內存和 CPU 使用率。

您能夠啟用或禁用的 CPU 使用率和內存使用的工具，通過點擊選擇工具下拉列表。調試器工具已表明打破事件、 輸出事件和 IntelliTrace 事件的三個軌道。

打破歷史上重大事件和 PerfTips 打破事件讓你看到每一節代碼花多長時間執行。

矩形代表從應用程序開始或恢復執行，直至調試器作出它暫停時的持續時間 （見圖 2)。

圖 2 斷裂事件和 PerfTips

矩形的起點指示你從哪里開始通過繼續步進 Shift + F11 F11 F10） 或執行到光標處 (Ctrl + F10) 命令 (F5)，執行應用程序。結束了該矩形指示由于它命中了斷點，完畢一個步驟或由于您使用了打破全部應用程序停止的位置。

最新的中斷事件的持續時間也顯示在調試器中的當前行末尾處的代碼。

這被稱為 PerfTips。它同意您監視性能沒有考慮你的眼睛離開你的代碼。

在關系圖下方的細節表中。也能夠看到歷史和打破事件和 PerfTips 表格格式的持續時間。假設你有 IntelliTrace，附加事件將顯示在表中。您還能夠使用篩選器顯示僅僅有調試器來查看僅僅有打破事件的歷史記錄。

CPU 和內存分析時間軸自己主動選擇時間范圍內，如您設置斷點并單步。

當遇到斷點時，當前時間范圍被重置。僅僅將最新的中斷事件顯示。

所選內容能夠擴大到包含最新的中斷事件。通過點擊一個打破事件矩形或通過單擊并拖動時間線上。您能夠覆蓋自己主動時間范圍選擇。

時間范圍選擇同意您關聯范圍上的 CPU 使用率和內存使用情況圖。以便您能夠理解代碼的特定部分的 CPU 和內存的特點。

圖繼續更新在該應用程序執行時，讓你幫我照看對 CPU 和內存作為您與您的應用程序進行交互。您能夠切換到內存選項卡。拍攝快照并查看內存使用情況的具體分項數字。

IntelliTrace 性能洞察力 IntelliTrace （在 Visual Studio 社區版本號中不可用） 讓你獲得很多其它的洞察性能調試托管的代碼時。

IntelliTrace 向調試器事件時間線中加入兩個軌道：輸出跟蹤和 IntelliTrace 軌道。這些事件包含信息顯示在輸出窗體中。再加上額外的事件收集的 IntelliTrace，如異常，ADO.NET，等等。在這些軌道發生的事件也是調試器事件表所看到的。

你能夠涉及的 IntelliTrace 事件穗狀花序的 CPU 使用率和內存使用情況圖。時間戳顯示你多久各種行動在您的應用程序。比如，您能夠在您的代碼中加入 Debug.WriteLine 語句，使用時間戳上輸出事件查看從一個語句到下一個執行所須要的多長時間。

提高性能和內存
如今。您已經看到該窗體的功能。我們將深入探討實際用途的工具。在本節中。我們步行通過求解一組稱為照片濾鏡的例子應用程序中的性能問題。這個應用程序將從云端下載圖片和從用戶的本地圖片庫載入圖片，這樣他能夠查看它們。并應用圖像篩選器。

假設你想要跟著，下載源碼從 aka.ms/diagtoolswndsample。由于性能是不同的不同的機器上。你會發現不同的數字。

它甚至會有所不同從執行。

慢啟動應用程序當您開始調試照片濾鏡應用程序時，你會發現它須要非常長的時間，要啟動應用程序和載入的圖片。

這是一個明顯的問題。

當您在調試應用程序的功能性問題時，你往往形成一個假設并開始調試在此基礎。在這樣的情況下，你能猜測圖片是緩慢載入。并尋找一個好的地方設置一個斷點，并考驗一下這個假說。

LoadImages 方法是一個偉大的地方，做到這一點。

開始和結束時的 LoadImages 函數設置斷點 （如圖所看到的的代碼中圖 3) 和開始調試 (F5)。

當代碼命中第一個斷點處時，按繼續 (F5) 再次跑到第二個斷點。

如今有兩個斷裂事件在時間軸中調試器事件。

圖 3 LoadImages 方法

第一步顯示應用程序執行僅 274 毫秒之前命中第一個斷點。第二部分演示了 10,476 女士要打第二個斷點之前在 LoadImages 函數中執行此代碼。您還能夠看到經過時間 PerfTip 在代碼中顯示同樣的值。所以你已經縮小到 LoadImages 函數問題。

若要獲取很多其它的信息和每一行須要多久的時間，又一次啟動調試所以你再打第一個斷點。這一次，逐句通過每一行代碼中方法以查看哪些行正在最長的時間。

從 PerfTips 和調試中斷事件的持續時間，你能夠看到 GetImagesFromCloud 花 7,290 女士、 LoadImagesFromDisk 須要 736 女士、 LINQ 查詢所需 1,322 女士和其余在小于 50 毫秒內完畢。

對于全部行時機所看到的圖 4。

行號顯示代表大課間活動，末尾處的線，所以線 52 意味著多長時間它接管了步線 51。 如今鉆進一步入 GetImagesFromCloud 方法。

圖 4 調試器事件表的每一個步驟顯示經過的時間

GetImagesFromCloud 方法執行兩個獨立的邏輯操作，如中所看到的圖 5。它從server和每張圖片的縮略圖中同步下載圖片的列表 （一次一個）。

您能夠通過取消您現有的斷點并將放在下面各行的新的時間這兩個操作：

圖 5 改進了代碼 （下圖） 與 GetImagesFromCloud 方法 （頂部）

又一次啟動調試進程并等待，直到該應用程序命中第一個斷點處。然后讓應用程序能夠執行 （通過按 f5 鍵以繼續） 向第二個斷點。這同意應用程序從云中檢索圖片的列表。

然后讓應用程序執行到第二個斷點來衡量從云端下載縮略圖。PerfTips 和打破事件告訴您花了 565 女士得到的圖片列表和 6,426 的 ms 下載縮略圖。

性能瓶頸是在你下載的縮略圖。

當你看著 CPU 使用率圖 （所看到的圖 6），該方法檢索的圖像列表。你能夠看到它是相對較高。圖形是相當平坦時表明這一過程花了非常長一段時間，等待網絡 I/O 的縮略圖下載。

圖 6 CPU 使用率圖指示延遲網絡輸入/輸出

為了盡量減少等待client和server之間的往返時間，馬上開始下載縮略圖的全部操作。等待他們通過等待完畢.NET System.Tasks 來完畢。

代替第 73 至 79 行 （從代碼中圖 5) 用下面的代碼：

// Download thumbnails var downloadTasks = new List<Task>(); foreach (var image in pictureList) {string fileName = image.Thumbnail;string imageUrl = ServerUrl + "/Images/" + fileName;downloadTasks.Add(DownloadImageAsync(new Uri(imageUrl), folder, fileName)); } await Task.WhenAll(downloadTasks);

當你的時候這個新的版本號時，你能夠看到須要僅僅有 2,424 女士來執行。這是關于四秒的改進。

調試內存增長和泄漏假設你看看內存使用情況圖診斷慢啟動時，您可能已經注意到內存使用量的急劇添加為啟動該應用程序。縮略圖的列表是虛擬化的列表，而僅僅有一個全然尺寸的圖像顯示在一段時間。

使用虛擬化的列表的長處之中的一個是它僅載入內容顯示在屏幕上，所以你不會期望非常多縮略圖在內存中一次。

要到這一問題的根本原因，你必須找到在代碼中內存增長出現。然后。拍取快照之前和之后的增長。

比較這些快照。你會發現最有助于生長在內存中的對象類型。

內存使用情況圖顯示了應用程序怎樣使用內存的高級視圖。還有計數器命名專用字節數為您的應用程序的性能。專用字節數是內存的衡量的分配給進程總量。這還不包含與其它進程共享的內存。它包含托管的堆、 本機堆、 線程堆棧和其它內存 （如載入的.dll 文件的私人部門）。

當開發一個新的應用程序或診斷問題與現有的一個，意外的增長的內存使用情況圖上會常常是你已經不表現如預期的代碼的第一個跡象。

看圖，您能夠使用調試器功能如斷點和單步執行來縮小感興趣的代碼路徑。你能夠從行號和持續時間顯示在調試器事件選項卡又一次確定圖 4負責意外增長線是線 52。LoadImagesFromDisk 方法調用。

拍攝快照，一般會針對意外的內存使用情況的下一步。

在內存選項卡，單擊拍攝快照button生成堆的快照。在斷點處或應用程序正在執行時。您能夠拍攝快照。

假設您知道哪一行代碼導致內存使用峰值。然后你有一個想法在哪里採取第一個快照。LoadImagesFromDisk 方法上設置斷點和拍攝快照，當您的代碼到達該斷點。此快照作為基線。

接下來，單步執行的 LoadImagesFromDisk 方法，并生成還有一個快照。如今，通過比較快照，你將能夠看到哪些托管的類型已加入到你跨過為函數調用的結果堆。圖再一次顯示了內存利用率穗正在調查 （如中所看到的圖 7)。您還能夠看到通過鼠標懸停圖形內存 47.4 MB。

它是一個好的主意來心理記數兆字節。所以您能夠稍后驗證您修復了有意義的影響。

有是內存使用量明顯激增

圖 7 有是內存使用量明顯激增

具體信息視圖顯示每一個快照的簡要的概述。概述包含快照的順序號，執行的時間 （以秒為單位） 時拍攝快照。堆的大小和數量的活堆上的對象。興許快照也會顯示變化的大小和對象計數從曾經的快照。

拍攝快照的過程列舉了僅僅有那些仍然生活在堆上的對象。也就是說，假設對象是符合垃圾回收條件。不會包含在快照中。

這樣的方式。你不須要操心當集合最后跑了。每一個快照中的數據是。仿佛剛剛發生垃圾回收。

顯示快照概述在堆的大小將低于專用字節內存使用情況圖表中顯示。專用字節數概要顯示全部類型的由您的進程分配的內存。而快照顯示的大小全部活對象在托管堆上。假設你看到在內存使用情況圖中。大量添加，但增長托管堆中的并不占多數的它，生長在內存中其它地方發生。

從快照概述中，您能夠打開堆視圖并調查按類型堆的內容。單擊第二個快照，在新選項卡中打開堆視圖的對象 （差異） 列中 diff 鏈接。單擊該鏈接將排序堆視圖中的類型由自曾經的快照創建的新對象的數目。這讓你感興趣頂部的表的類型。

堆視圖快照 （見圖 8) 有兩個主要部分：頂部窗格和下部窗格中引用圖中的對象類型表。對象類型表顯示的名稱、 數量和大小的每一個對象類型時拍攝快照。

中 Diff 模式的堆視圖快照

圖 8 中 Diff 模式的堆視圖快照

幾個在堆視圖類型是從框架。

假設你有僅我的代碼啟用 （默認值）。這些都是在您的代碼中引用類型或由您的代碼類型引用的類型。使用此視圖，您能夠識別一個類型從我們靠近頂部的 table—PhotoFilter.ImageItem 的代碼。

在圖 8。你能夠看到計數 Diff 列顯示自曾經的快照創建的 137 新映像對象。頂五個新對象類型都有同樣數量的新的對象，所以這些可能相關。

讓我們看看第二個窗格。參考圖。假設你期望要清理垃圾回收器的類型，但它仍顯示在類型表中，根的路徑能夠幫助您跟蹤下什么持有該引用。

到根的路徑是參考圖中這兩種視圖之中的一個。到根的路徑是自底向上樹顯示完整的圖形類型生根您所選的類型。假設還有一個應用程序對象保存了一個引用，植根的對象。

不必要的根的對象往往是在托管代碼中內存泄露的原因。

引用的類型，還有一個視圖。則相反。

為在對象類型表中，選擇此視圖顯示其它類型的類型引用了您選定的類型。此信息能夠有助于確定為什么在很多其它的內存比預期堅持所選類型的對象。這是實用的現狀調查。由于類型可能會使用很多其它的內存比預期。但他們并不比它們的用處。

在對象類型表中選擇 PhotoFilter.ImageItem 行。參考圖將更新以顯示關系圖的映像。在引用類型視圖中。您能夠看到映像對象保留共 280 的字符串對象和 140 每一個框架的三種類型：StorageFile、 StorageItemThumbnail 和 BitmapImage。

總大小使它看起來好像貢獻由映像對象保留的內存的添加最大字符串對象。專注于總大小 Diff 列使非常有意義，但數目不會導致的根本原因。

一些框架類型，如 BitmapImage，僅僅有極少量的舉行在托管堆上的內存總量。

BitmapImage 實例的數量是一個更有說服力的線索。記得在照片濾鏡的縮略圖的列表虛擬的所以它應該載入這些映像上的需求，并使其可作為垃圾回收。當它做。然而，看起來好像提前載入全部縮略圖。結合你如今了解什么 BitmapImage 對象被冰山，繼續專注于那些進行調查。

PhotoFilter.ImageItem 在參考圖中。右擊并選擇轉到定義映像在編輯器中打開源文件。

映像定義的成員字段，m_photo，即 BitmapImage，如中所看到的圖 9。

代碼引用 m_photo 的成員字段

圖 9 代碼引用 m_photo 的成員字段

第一個代碼路徑引用 m_photo 是屬性的 get 方法的照片，它是屬性的數據綁定到 ListView 在 UI 中的縮略圖。它看起來像 BitmapImage 正在載入 （和因此解碼在本機堆上） 上的需求。

引用 m_photo 的第二個代碼路徑是 LoadImageFromDisk 的功能。這個項目是相應用程序的啟動路徑。

應用程序啟動時，它獲取呼吁被顯示，每一個圖像。

這有效地預載入 BitmapImage 的全部對象。這樣的行為不利于虛擬列表視圖中，作為已分配的全部內存，不管列表視圖中顯示圖像的縮略圖。該預載入算法不能非常好地擴展。很多其它的圖片，你有在你的圖片庫中。啟動內存成本也就越高。

按需載入 BitmapImage 對象是更具可擴展性的解決方式。

后停止調試器。請凝視掉線 81 和 82 在 LoadImageFromDisk 載入 BitmapImage 實例。為驗證您已經固定內存性能問題而不會破壞應用程序的功能。然后又一次執行同樣的實驗。

按 F5，你就會看到上圖總內存使用量是如今僅僅有 26.7 MB （見圖 10)。

以還有一組的快照之前、 之后調用 LoadImagesFromDisk，然后比較他們。你會看到仍然是 137 的映像對象，但沒有 BitmapImages （見圖 11)。BitmapImages 將載入需求上，一旦你讓應用程序繼續啟動。

內存圖在固定的引用問題

圖 10 內存圖在固定的引用問題

參考圖后固定內存的問題

圖 11 參考圖后固定內存的問題

正如前面提到的此調試器集成的工具還支持拍照的本機堆或托管和本機堆同一時候。堆你配置文件為基礎上的調試器，您正在使用：

僅托管調試器僅僅需托管堆的快照。
僅限本機調試器 （本機項目的默認值） 僅僅須要本機堆快照。
混合模式調試器須要的托管和本機堆快照。
您能夠調整此設置對您的項目屬性的調試頁。

當不啟用調試執行工具
它是重要的是提及須要額外開銷介紹了當您測量與調試器的性能。主類的開銷來自您通常執行的應用程序的調試版本號的事實。

您公布到用戶的應用程序將公布版本號。

在調試版本號中。編譯器保持了盡可能接近原始的源碼作為可能的結構和行為的可執行文件。正如您期望在調試時，一切應該工作。還有一方面。公布版本號試圖優化代碼的性能減少的調試體驗的方式。一些例子包含襯砌中的函數調用和常數變量，移除未使用的變量和代碼路徑和存儲變量信息可能無法讀取由調試器的方式。

全部這一切意味著 CPU 密集型代碼能夠有時執行速度顯著變慢在調試版本號中。非 CPU 密集型的操作。如磁盤 I/O 和網絡調用將採取同樣多的時間。通常不是記憶行為，意味著泄漏的內存會泄露和低效的內存的使用仍將顯示作為大量添加這兩種情況區別非常大。

它附加到目標應用程序時，將由調試器加入其它開銷的類來考慮。調試器截獲模塊載入和異常的事件。它也提供其它所需的工作讓你設置斷點和步驟。

Visual Studio 會盡力篩選這樣的類型的開銷從性能的工具，但仍有少量的開銷。

假設你看到一個應用程序的公布版本號中的一個問題。它將差點兒總是復制在調試版本號中，但不是一定在附近的其它方式。為此，調試器集成工具旨在幫助您在開發過程中主動地發現性能問題。假設您在調試版本號中發現的問題，你能夠翻到公布版本號。看假設這一問題影響以及公布版本號。

可是，您可能決定往前走并在調試版本號中解決該問題，假設你決定這是預防性能良好的工作 （也就是說，修復問題減少以后遇到性能問題的機會）。假設您確定問題是非 CPU 密集型 （磁盤或網絡 I/O），或假設您想要加快調試版本號，所以在開發過程中，您的應用程序是迅捷。

報告性能問題時在公布版本號中，您想要確保您能夠復制和驗證你已經攻克了問題。最好的辦法做到這一點是翻轉您為公布模式的生成與所報告的問題相符的環境中執行的工具不使用調試器。

假設你想測量業務持續時間，調試器--集成的工具將僅僅能精確到內幾十毫秒量較少的系統開銷。

假設你須要更高一級。執行不用調試器工具是準確性的一個更好的選擇。

總結
你能夠通過下載 Visual Studio 2015 RC 嘗試視覺工作室 2015 年新的診斷工具調試器窗體。使用這些新的集成調試工具能夠幫助您提高性能，您在調試您的應用程序。

轉載于:https://www.cnblogs.com/blfbuaa/p/7085550.html

總結

以上是生活随笔為你收集整理的VS2015--win32project配置的一些想法之在 Visual Studio 2015 中进行调试的同一时候分析性能...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。