使用 Visual Studio 分析器找出應用程序瓶頸


VS的性能分析工具

性能分析工具的選擇

打開一個“性能分析”的會話:Debug->Start Diagnotic Tools Without Debugging(或按Alt+F2),VS2013在Analysis菜單中。 

性能分析 
性能分析

 

CPU Usage

檢測CPU的性能,主要用於發現影響CPU瓶頸(消耗大量CPU資源)的代碼。

GPU Usage

檢測GPU的性能,常用於圖形引擎的應用(如DirectX程序),主要用於判斷是CPU還是GPU的瓶頸。

Memory Usage

檢測應用程序的內存,發現內存。

Performance Wizard

性能(監測)向導,綜合檢測程序的性能瓶頸。這個比較常用,下面再逐一說明。

性能(監測)向導

  1. 指定性能分析方法; 
    性能分析方法 
    性能分析方法

    CPU Sampling(CPU采樣): 
    進行采樣統計,以低開銷水平監視占用大量CPU的應用程序。這個對於計算量大的程序可大大節省監控時間。 
    Instrumentation(檢測): 
    完全統計,測量函數調用計數和用時 
    .NET memory allocation(.NET 內存分配): 
    跟蹤托管內存分配。這個好像只有托管代碼(如C#)才可用,一般以C++代碼好像不行。 
    Resource contention data(並發): 
    檢測等待其他線程的線程,多用於多線程的並發。
  2. 選擇要檢測的模塊或應用程序;
  3. 啟動分析程序進行監測。

性能分析報告

程序分析完成之后會生成一個分析報告,這就是我們需要的結果。 

性能分析報告 
性能分析報告概要

 

視圖類型

有幾個不同的視圖可供我們切換,下面加粗的部分是個人覺得比較方便和常用的視圖。 
Summary(概要):整個報告概要說明 
Call Tree(調用樹):以樹形表格的方式展開函數之間的關系。 
Module(模塊):分析調用的不同的程序模塊,如不同的DLL、lib模塊的耗時 
Caller/Callee(調用與被調用):以數值顯示的調用與被調用的關系 
Functions(函數統計):以數值顯示的各個函數的執行時間和執行次數統計值 
Marks(標記): 
Processers(進程): 
Function Detials(函數詳情):以圖表的方式形象地顯示:調用函數-當前函數-被調用子函數之間的關系和時間比例。 


調用樹 
調用樹 
函數詳情 
函數詳情 
函數統計 
函數統計 

 

專用術語

如果是第一次看這報告,你還不一定能看懂。你需要先了解一些專用術語(你可以對照着Call Tree視圖和Functions視圖去理解): 
Num of Calls:(函數)調用次數 
Elapsed Inclusive Time:已用非獨占時間 
Elapsed Exclusive Time:已用獨占時間 
Avg Elapsed Inclusive Time:平均已用非獨占時間 
Avg Elapsed Exclusive Time:平均已用獨占時間 
Module Name:模塊名稱,一般為可執行文件(.exe)、動態庫(.dll)、靜態庫(.lib)的名稱。

也許看完你還迷糊,只要理解什么是獨占與非獨占你就都明白了。

什么是獨占與非獨占

非獨占樣本數是指的包括了子函數執行時間的總執行時間 
獨占樣本數是不包括子函數執行時間的函數體執行時間,函數執行本身花費的時間,不包括子(函數)樹執行的時間。

解決應用案例問題

我們已經大致了解了VS2015性能分析工具的使用方法。現在回歸本質,解決上面提及的應用案例的問題。

1、我們選擇Function Detials視圖,從根函數開始依據百分比最大的項選擇,直到選擇PrintPrimeSum,這時可以看到如下圖: 

找出性能瓶頸1 
找出性能瓶頸1


我們可以看到IO占了50%多(49.4%+9.7%)的時間,所以IO是最大的性能瓶頸。其實,有一定編程經驗的人應該都能明白,在控制台輸出信息是很耗時的。我們只是需要結果,不一定非要在控制中全部輸出(這樣還不便查看),我們可以將結果保存到文件,這樣也比輸出到控制台快。

 

注:上圖所示的時間,應該是非獨占時間的百分比。

知道了瓶頸,就改進行代碼優化吧:

void PrintPrimeSum() { int64_t startTime = GetSysTimeMicros(); std::ofstream outfile; outfile.open("D:\\Test\\PrimeSum.dat", std::ios::out | std::ios::app); int count = 0; int64_t sum = 0; for (int i = 10000; i <= 100000; i++) { if (IsPrime(i)) { sum = CalculateSum(i); outfile << sum << "\t"; count++; if (count % 10 == 0) { outfile << std::endl; } } } outfile.close(); int64_t usedTime = GetSysTimeMicros() - startTime; int second = usedTime / 1000000; int64_t temp = usedTime % 1000000; int millise = temp / 1000; int micros = temp % 1000; std::cout << "執行時間:" << second << "s " << millise << "' " << micros << "''" << std::endl; }

 

再次執行,發現時間一下減小到:3s 798’ 218”。效果很明顯!


2、但這還不夠,繼續檢查別的問題,對新代碼再次用性能分析工具檢測一下。 

找出性能瓶頸2 
找出性能瓶頸2

 

我們發現IsPrime函數占用了62%的時間,這應該是一個瓶頸,我們能不能對其進行算法的優化?仔細想想,上面求質數的方法其實是最笨的方法,稍微對其進行優化一下:

// 判斷整數n是否為質數 bool IsPrime(int n) { if (n < 2) { return false; } if (n == 2) { return true; } //把2的倍數剔除掉 if (n%2 == 0) { return false; } // 其實不能被小於n的根以下的數整除,就是一個質數 for (int i = 3; i*i <= n; i += 2) { if (n % i == 0) { return false; } } return true; }

再次執行,發現時間一下減小到:1s 312’ 75”,幾乎減了一半的時間。

3、這還是有點慢,再看看還能不能進行優化。對新代碼再次用性能分析工具檢測一下。 

找出性能瓶頸2 
找出性能瓶頸2

 

CalculateSum函數占了88.5%的時間,這絕對是影響目前程序性能的主要因素。對其進行。仔細想想,求1到N的和其實就是求1、2、3 … N的等差數列的和。優化代碼如下:

// 計算1到n之間所有整數的和 int64_t CalculateSum(int n) { if (n < 0) { return -1; } //(n * (1 + n)) / 2 return ( n * (1 + n) ) >> 1; }
  • 再次執行,發現時間一下減小到:0s 91’ 6”,一秒中之內,基本上可以滿足要求子。

總結

程序性能調優,就是數上面這樣一點點地改進的過程,直到滿足應用的要求。上面只用了一個視圖的一種統計指標(各函數所用時間占總時間的百分比),就解決了問題。對於大型的復雜應用程序,我們可以結果多種視圖的多種統計指標進行綜合判斷,找出程序性能的瓶頸!

 

 

 

使用 Visual Studio 分析器找出應用程序瓶頸

Hari Pulapaka and Boris Vidolov

本文討論:

以性能瓶頸為目標

應用程序代碼分析

比較分析數據

性能報告

本文使用了以下技術: 

Visual Studio 2008

在過去十年間,涌現了許多新的軟件技術和平台。每種新技術都要求掌握專門的知識才能創建出性能良好的應用程序。現在,由於各種 Internet 技術(如博客)使失望的用戶可輕松地否定您的應用程序,因此您確實需要將性能放到首要位置。在計划早期,就應添加響應性能要求並創建原型來確定可能的技術限制。在整個開發過程中,還應衡量應用程序的各個性能方面以發現可能的性能下降,同時確保速度較慢情形下的測試人員文件並跟蹤其錯誤。

即使擁有最好的計划,仍必須在產品開發過程中調查性能問題。在本文中,我們將向您展示如何使用 Visual Studio® Team System Development Edition 或 VisualStudio Team Suite 來確定應用程序中的性能瓶頸。將通過演練一個示例性能調查來向您介紹 Visual Studio 分析器。請注意,盡管我們在本文中是使用 C# 來編寫代碼示例,但是此處的大部分示例對於本機 C/C++ 和 Visual Basic® 代碼也同樣有效。

 

應用程序分析

我們將使用先前提及的兩個 Visual Studio 版本所附帶的分析器。首先編寫一個用於繪制 Mandelbrot 不規則圖形的小型示例項目(如圖 1 所示)。該應用程序不是非常有效,並且需要約 10 秒鍾才能繪制出不規則圖形。

圖-1 性能測試的目標程序

 

要開始調查,從 Visual Studio 2008 的新“Analyze”(分析)菜單啟動“Performance Wizard”(性能向導)。在 Visual Studio 2005 中,此功能可從“工具”|“性能工具”菜單獲得。從而啟動一個包含三個步驟的向導,其中第一步是指定目標項目或網站。第二步提供兩種不同的分析方法:采樣和檢測。(有關這些分析方法的詳細信息,請參閱“性能分析解釋”側欄。)現在,我們將選取默認值。

向導完成后,顯示一個“Performance Explorer”(性能資源管理器)對話框並創建一個新的性能會話。此會話包含目標應用程序(在我們的示例中為 Mandel)並且沒有報告。要啟動分析,單擊工具窗口工具欄中的“Launch with Profiling”(啟動並分析)按鈕。

應用程序繪制完不規則圖形后,立即關閉窗體停止分析。Visual Studio 自動將一個新創建的報告添加到性能會話中並開始進行分析。分析完成后,Visual Studio 分析器會顯示“Performance Report Summary”(性能報告摘要),列出開銷最大的函數(請參見 圖 2)。報告以兩種方式顯示這些函數。第一種方式衡量所列出函數直接或間接執行的工作。對於每個函數,數字代表在函數主體及其所有子調用中收集的積累樣本。第二個列表不計算在子調用中收集的樣本。此摘要頁面顯示 Visual Studio 分析器在執行 DrawMandel 方法期間收集了 30.71%的樣本。剩余 69%的樣本則分散在其他各個函數間,在此就不加贅述。要了解更多有關報告選項的信息,請參閱側欄“報告可視化選項”。

 

圖-2 性能測試顯示開銷較大的函數調用

請查看報告的“Call Tree”(調用樹)視圖(如圖 3 所示),“Inclusive Samples %”(包含樣本 %)列代表在函數及其子項中收集的樣本。“Exclusive Samples %”(獨占樣本 %)列代表僅在函數主體中收集的樣本。可看到 DrawMandel 方法直接調用 Bitmap.SetPixel。盡管 DrawMandel 自身占據了總樣本的 30.71%,但 Visual Studio 分析器從 Bitmap.SetPixel 及其子項收集了 64.54%的樣本。其中 Bitmap.SetPixel 主體僅占 0.68%(因此它並未顯示在摘要頁面上)。但是,Bitmap.SetPixel 通過其子項產生了大部分處理。它才是應用程序的真正瓶頸。

 

圖-3 被測應用程序的調用樹示例

顯然地,Bitmap.SetPixel 對於 Mandel 項目而言並非最佳。我們的應用程序需要一種更快的方式來訪問窗體上的所有像素。幸運的是,位圖類還提供有另一個有用的 API:Bitmap.LockBits。此函數允許程序直接寫入位圖內存,從而減少了設置單個像素的開銷。此外,為優化繪圖,我們將創建一個純整數數組並用每個像素的顏色值加以填充。隨后,通過單個操作將該數組的值復制到位圖中。

 

優化應用程序

性能分析解釋

使用采樣方法 進行分析時,分析器以一種類似於調試程序的方式附加到正在運行的進程。然后,分析器會定期中斷進程並檢查哪個函數處於堆棧頂部以及該函數的代碼路徑。換句話說,Visual Studio 分析器收集當前進程狀態的樣本。采樣是一種非入侵式統計型分析方法。在函數中收集的樣本越多,函數可能執行的處理就越多。

Visual Studio 分析器還會收集有關導致此執行的調用路徑的信息。因此,此工具可在分析收集的數據后顯示整個調用堆棧。默認情況下,Visual Studio 分析器每 1 千萬個 CPU 周期收集一個樣本。除 CPU 周期外,還可能在出現其他事件(如頁面錯誤、系統調用、CPU 高速緩存缺失等等)時執行采樣。分析會話的屬性控制分析器的取樣對象以及頻率。

作為一個低開銷解決方案,采樣常常是推薦選項。但值得注意的是,采樣僅在程序有效使用 CPU 時收集信息。因此,當進程在等待磁盤、網絡或任意其他資源時,Visual Studio 分析器均不會收集樣本。這就是如果應用程序並未有效使用 CPU,建議使用檢測分析的原因。

在檢測模式中,Visual Studio 分析器通過在每個函數的開頭和結尾處注入特殊指令(稱為探針)來修改(檢測)二進制文件。探針允許分析器度量運行每個函數所花的時間。此外,分析器還會在每個外部函數調用周圍添加一對探針,從而可確定這些外部調用的開銷。

通過使用檢測分析,可准確測量各種數據,如運行函數所花時間(“經過的時間”)、函數的調用次數以及函數正在使用 CPU(“應用程序時間”)且未被 OS 切換出來的時間。檢測的缺點是收集了大量數據,因而需要花費更長的分析時間。此外,此分析模式還具有更高的運行時開銷。更高開銷可能不經意間更改所分析應用程序的性能特征。

通過同時使用采樣和檢測,還可收集基於 Microsoft® .NET Framework 的應用程序的內存分配數據。用戶可使用性能會話屬性頁面啟用和調整 .NET 內存分配數據的收集。它通常被稱為內存分析,並且有大量關於該主題的 MSDN® 文檔。請注意,它是分析器中唯一一個僅用於 .NET Framework 兼容代碼的功能。對於其他功能,Visual Studio 分析器在本機 C/C++ 和基於 .NET 的應用程序之間完全相同。

 

接下來修改 DrawMandel 方法以使用 LockBits 而非 SetPixel,並看看此更改會產生何種性能。創建位圖后,添加以下代碼行來鎖定位圖位並獲得指向位圖內存的指針:

  1. BitmapData bmpData =   
  2.     bitmap.LockBits(  
  3.         new Rectangle(0, 0, Width, Height),   
  4.         ImageLockMode.ReadWrite,   
  5.         bitmap.PixelFormat);  
  6. IntPtr ptr = bmpData.Scan0;  
  7. int pixels = bitmap.Width * bitmap.Height;  
  8. Int32[] rgbValues = new Int32[pixels];  


然后,在設置像素的內部循環中,注釋掉對 Bitmap.SetPixel 的調用並用新語句加以替換,具體如下:

  1. //bitmap.SetPixel(column, row, colors[color]);  
  2. rgbValues[row * Width + column] =   
  3.     colors[color].ToArgb();  

此外,添加以下代碼行來將數組復制到位圖內存中:

  1. Marshal.Copy(rgbValues, 0, ptr, pixels);  
  2. bitmap.UnlockBits(bmpData);  

 

現在,如果重新在分析器中運行應用程序,可以看到不規則圖形的繪制速度幾乎快了三倍(請參見圖 4)。請注意,新性能報告的摘要頁面顯示 DrawMandel 的主體直接占據了總樣本的 83.66%。由於我們優化了繪圖,瓶頸現在變成了不規則圖形的計算。

 

圖-4 修訂代碼的性能分析

現在,我們將更進一步優化該計算。遺憾的是,此次需要查找單個函數中的瓶頸。DrawMandel 是一個比較復雜的方法,因而很難知道應關注哪些計算。幸運的是,Visual Studio 2008 采樣分析器還默認收集行級數據,從而有助於確定函數中的哪些行開銷最大。

要查看行級數據,需從其他角度查看性能報告。從“Current View”(當前視圖)菜單切換到“Modules”(模塊)視圖。與“Call Tree”(調用樹)視圖不同,“Modules”(模塊)視圖不會顯示在父函數上下文中各函數的相互調用方式以及這些調用的開銷等信息。相反,“Modules”(模塊)視圖包含每個可執行文件(程序集或 DLL)以及該可執行文件中每個函數的累積總樣本數。Visual Studio 分析器從所有調用堆棧累積該數據。

“Modules”(模塊)視圖比較適合於觀察更大的圖片。例如,如果按“Exclusive Samples %”(獨占樣本 %)列排序,可以看到 Mandel.exe 自身執行 87.57%的處理。作為優化后的結果,GDI+ 占用不到 3%的處理。展開這些模塊,可以看到單個方法的相同信息。此外,在 Visual Studio 2008 中,除函數級以外,還可展開樹來查看單個行甚至這些行中單個指令的相同數據(請參見圖 5)。

Figure 5 跳到分析的代碼行

跳到源代碼可查看如圖 6 所示的代碼。代碼在最內部循環中計算平方根。此操作開銷很大且占用 18% 的總應用程序處理。圖 6 中突出顯示的行顯示了可優化的代碼。第一行使用了一個不必要的平方根,而第二行對於 while 循環是不變的。

原始代碼

  1. for (int column = 1; column < Width; column++)  
  2. {  
  3.  y = yStart;  
  4.  for (int row = 1; row < Height; row++)  
  5.  {  
  6.   double x1 = 0;  
  7.   double y1 = 0;  
  8.   int color = 0;  
  9.   int dept = 0;  
  10.   while (dept < 100 && Math.Sqrt((x1 * x1) + (y1 * y1)) < 2)  
  11.   {  
  12.    dept++;  
  13.    double temp = (x1 * x1) - (y1 * y1) + x;  
  14.    y1 = 2 * x1 * y1 + y;  
  15.    x1 = temp;  
  16.    double percentFactor = dept / (100.0);  
  17.    color = ((int)(percentFactor * 255));  
  18.   }  
  19.   //Comment this line to avoid calling Bitmap.SetPixel:  
  20.   //bitmap.SetPixel(column, row, colors[color]);  
  21.   //Uncomment the block below to avoid Bitmap.SetPixel:  
  22.   rgbValues[row * Width + column] = colors[color].ToArgb();  
  23.   
  24.   y += deltaY;  
  25.  }  
  26.  x += deltaX;  
  27. }  

優化后的代碼

  1. for (int column = 1; column < this.Width; ++column)  
  2. {  
  3.  y = yStart;  
  4.  int index = column;  
  5.  for (int row = 1; row < Height; row++)  
  6.  {  
  7.   double x1 = 0;  
  8.   double y1 = 0;  
  9.   int dept = 0;  
  10.   double x1Sqr, y1Sqr;  
  11.   while (dept < 100 && ((x1Sqr = x1 * x1) + (y1Sqr = y1 * y1)) < 4)  
  12.   {  
  13.    dept++;  
  14.    double temp = x1Sqr - y1Sqr + x;  
  15.    y1 = 2 * x1 * y1 + y;  
  16.    x1 = temp;  
  17.   }  
  18.   rgbValues[index] = colors[((int)(dept * 2.55))].ToArgb();  
  19.   index += Width;  
  20.   
  21.   y += deltaY;  
  22.  }  
  23.  x += deltaX;  
  24. }    

 

 

修改后,重新分析應用程序並檢查優化后代碼的性能。生成和運行應用程序后,現在在 1-2 秒內就能重新繪制不規則圖形。因而顯著減少了應用程序的啟動時間。

Visual Studio 2008 包含一個可比較兩個性能報告的新功能。為實際了解此功能,我們在分析器中重新運行應用程序並捕獲最新的性能報告。要查看兩個應用程序版本之間的差異,在“Performance Explorer”(性能資源管理器)中選擇原始報告和最新報告。右鍵單擊報告,並單擊上下文菜單中的“Compare Performance Reports”(比較性能報告)選項。此命令將生成一個新的報告,顯示所有函數以及兩個報告中的該函數的“Exclusive Samples %”(獨占樣本 %)值之間的差異。由於我們削減了總體執行時間,所以 DrawMandel 的相對百分比從 31.76 上升到 70.46。

為更好地查看實際優化效果,將比較選項窗格中的列更改為“Inclusive Samples”(包含樣本)(請參見圖 7)。同時將閾值增加到 1500 個樣本以忽略微小的波動。此外,您可能已注意到:在默認情況下,報告顯示負數或首先顯示優化最少的函數(因為它常用於查找性能下降)。但是,出於優化目的,我們將反向排序 Delta 列,以便可以在頂部看到最優化的函數。請注意,DrawMandel 及其子函數的樣本數從 2,064 變為 175。超過了十倍的優化!為展示所取得的性能改進,可復制並粘貼該報告的任何部分。

 

圖-7 比較 DrawMandel的優化結果 

 

目標分析

報告可視化選項

Visual Studio 可 使用以下各種性能報告選項以多種方式查看性能數據:“Call Tree”(調用樹)、“Modules”(模塊)、“Functions”(函數)以及其他選項。打開報告時默認顯示“Summary”(摘要)視圖。例如,要在 Visual Studio 2008 中查找產生大多數處理的調用路徑,請從“Current View”(當前視圖)菜單選擇“Call Tree”(調用樹)視圖。(在 Visual Studio 2005 中,在報告底部選擇“調用樹”選項卡。)“Call Tree”(調用樹)視圖包含所有調用堆棧的聚合樹。“Inclusive Samples %”(包含樣本 %)列顯示這些代碼路徑中每個分支的總開銷。沿着開銷最大的分支,就可以找到性能瓶頸。

在 Visual Studio 2008 中,分析器團隊添加了兩個新的功能來簡化性能報告的使用。添加的第一個功能是降噪選項。默認情況下,報告現在會裁掉不重要的小函數,從而使用戶能很容易地查看具有更大影響的函數。此選項通常稱為剪裁。另外,團隊通過將自身不進行任何處理而只調用其他函數進行處理的函數放到一起,從而減少了調用樹的深度。Visual Studio 分析器將其稱為折疊。

性能報告中的降噪選項控制剪裁和折疊的閾值。如果在性能報告中查找特定函數時遇到問題,則可關閉降噪選項。

對 Visual Studio 2008 中調用樹的第二個較大的改進是“Hot Path”(熱路徑)按鈕和相應上下文菜單。“熱路徑”會突出顯示程序中開銷最大的代碼路徑,並沿着該路徑向下直至看到單個函數所執行(並且不是委派)的重大處理。然后,“熱路徑”會突出顯示該函數。如果有兩個或多個單獨的重要代碼路徑,則“熱路徑”將停在樹中出現分支的位置。如果“熱路徑”為應用程序提供了多個分支,則可選擇最感興趣的一個,並對該特定分支重新應用“熱路徑”。

 

 

 

 

 

 

 

 

 

--------------------

Visual Studio 2017 RC的最新文檔,請參看https://docs.microsoft.com/zh-cn/visualstudio/.

你可以使用Visual Studio Profiling工具來分析你的應用程序中的性能問題。本文展示了如何使用采樣數據。

采樣是一種統計學習方法,可以向你展示:在應用中,那一部分做了絕大多數的用戶模型工作。采樣是一個很好的方式用來尋找從哪里可以加速你的程序。

在指定的時間間隔,采樣方法收集在應用程序中執行的函數的信息。當你完成一個分析的運行后,被分析的數據的摘要視圖展示了最活躍的函數,稱之為Hot Path,應用程序中的大多數的工作被執行。視圖還列出了執行功能的最獨特的工作,並且提供了一個時間線的圖表,你可以使用這個圖標只考慮其中一部分的抽樣結果。

如果采樣的方法不能給你你想要的結果,其他的分析工具收集方法能夠提供不同的信息,可能對你有幫助,關於這些方法的更多信息請參看 https://msdn.microsoft.com/en-us/library/ms182374.aspx

 

小貼士:

如果你的配置文件的代碼調用Windows函數,你應該確保你有最新的PDB文件。沒有這些文件,你的報告視圖將會列出Windows函數的名字,它們往往很神秘並且很難理解的。關於更多的如何確保你有你需要的文件的信息請參考:https://msdn.microsoft.com/en-us/library/89axdy6y.aspx

 

創建並且運行一個性能會話

為了得到你需要分析的數據,你必須首先創建一個性能會話,然后運行這個會話,性能向導可以使你兩者兼顧。

如果你不是分析一個Windows桌面應用程序或asp.NET應用程序,你必須使用其他的某一種分析工具,參看 https://msdn.microsoft.com/en-us/library/mt210448.aspx.

步驟一:為了創建並且運行一個性能會話:

1.在VS中打開解決方案,設置配置為Release。(在工具欄中找到“解決方案配置”,把Debug改成Release)

注意:如果你不是你正在使用的這台電腦的管理員,當你使用profiler的時候你應該以管理員的身份運行VS。(右擊VS的運行圖標,然后點擊“以管理員身份運行”)

2.在“調試”菜單中,單擊“性能分析器”

3.單擊“性能向導”選項,並單擊“開始”

4.單擊“CPU采樣”選項,單擊“完成”

5.你的應用程序啟動,並且分析器開始收集數據

6.操作功能可能包含性能問題

7.如你通常所做的,關閉應用程序

 

當你運行完成這個應用后,被分析數據的摘要視圖出現在VS的主窗口中,新的會話圖標出現在性能探測器窗口。

步驟二:分析采樣數據

當你完成一個性能會話時,分析報告的摘要視圖出現在VS的主窗口中。

我們建議你從檢查Hot Path開始分析你的數據,函數列表就是做的絕大多數的工作,最后通過使用摘要時間表分析其他函數。你可以查看配置建議和錯誤列表中的警告。

請注意,抽樣方法可能不能給你你所需要的信息。例如,只有當應用程序正在執行用戶模式代碼時采樣才會被收集。因此,一些功能,例如輸入和輸出操作,是不能被采樣的。分析工具提供了一些方法的集合,能夠使你專注分析一些重要的數據。有關其他方法的更多信息請參看https://msdn.microsoft.com/enus/library/ms182374.aspx.

圖中的每一個標號區域對應一個過程的步驟:

為了分析采樣數據:

1.在摘要視圖中,Hot Path展示了你的應用程序中具有最高包容樣本的分支。當數據被收集時,這是最活躍的執行路徑。高包容值可以表明該算法生成的調用樹可以優化。發現代碼中的函數中的最短路徑,注意,路徑可以包括系統功能和在外部模塊中的系統功能。

(1)Inclusive Samples:表明函數做了多少工作,以及哪些函數調用它。高包容性計數指向函數最昂貴的整體。

(2)Exclusive Samples:表示多少工作是由函數體中的代碼做的,不包括調用它的函數做的工作。高獨家計數表示函數本身的性能瓶頸。

2.單擊函數名稱來顯示分析數據的功能細節視圖。功能細節視圖提供了一個分析數據的圖形化視圖選擇功能,顯示該函數調用的所有函數以及調用該函數的所有函數。

調用函數和被調用函數的塊的大小表示函數調用的相對頻率。

你可以單擊調用函數或被調用函數的名稱,使其顯示所選函數的函數細節。

較低的平面的功能細節窗口顯示功能代碼本身。如果你檢查代碼發現一個優化其性能的機會,單擊原文件的名字,從而在VS的編輯器中打開該文件。

3. 繼續你的分析,通過在視圖的下拉列表中選擇 Summary回到摘要視圖。然后在Functions Doing the Most Individual Work中檢查函數。這個列表顯示具有最高獨家樣本的函數。這些函數中的函數體的代碼執行重要工作,你可以對其進行優化。為了進一步分析一個特定的功能,單擊函數的細節視圖來顯示它。

繼續你的調查分析,你可以重新分析被分析數據的一段,通過使用摘要視圖中的時間線,向你展示被選擇部分的Hot Path和Functions Doing Most Individual Work,關注於時間線上的一個小的峰值,這可能會揭示出昂貴的調用樹和函數,這些內容在整個分析運行中可能沒有顯示。

為了重新分析一小段,在時間線中選擇一小段,然后單擊Filter by Selection。

4.分析器還使用一套規則提出改善分析運行的方式,並確定可能的性能問題。如果找到一個問題,在錯誤列表中就會顯示一個警告窗口。

視圖菜單上單擊錯誤列表,然后打開錯誤列表窗口。

為了看到這個有錯誤的函數,提出了一個警告功能的細節視圖中,雙擊警告。

為了查看詳細信息警告,右擊錯誤,然后單擊顯示錯誤幫助

 

步驟三:修改代碼並重新運行會話

在你發現有一個或多個功能可以進行優化時,你可以重復運行分析並比較數據的差異,從而得到你更改后的應用程序的性能。

修改代碼並重新運行分析器

1.修改你的代碼

2.為了打開Performance Explorer。在Debug菜單中單擊“Profiler”,然后單擊“ Performance Explorer ”,然后單擊“Show Performance Explorer”

3.在Show Performance Explorer中,右擊你想運行的會話,然后單擊“啟動與剖析”

4.你重新運行一個會話以后,另一個數據文件就會被添加到報告文件夾中,選擇原始的分析數據和新的分析數據,右擊選擇,然后單擊“比較性能報告”

一份新的報告在窗口中打開,顯示比較結果。關於如何使用比較視圖的更多信息,參看:https://msdn.microsoft.com/en-us/library/bb38575


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM