逐步解說：剖析應用程式
本逐步解說將示範如何剖析應用程式以找出效能問題。
在這個逐步解說中，您會逐步執行剖析 Managed 應用程式的程序，並使用取樣和檢測以隔離並識別應用程式中的效能問題。
在這個逐步解說中，您將會依照下列步驟進行：
使用取樣方法剖析應用程式。
分析取樣的剖析結果，找出並修正效能問題。
使用檢測方法剖析應用程式。
分析檢測的剖析結果，找出並修正效能問題。
必要條件
Microsoft Visual Studio 2010.
對 C# 具有中等程度的了解。
若要使用程式碼剖析所提供的資訊，您手邊最好能有偵錯符號資訊。
使用取樣方法進行剖析
取樣是一種剖析的方法，會定期輪詢有問題的處理序 (Process) 以判斷使用中的函式。 產生的資料會提供計數，表示在取樣處理序時，有問題的函式位於呼叫堆疊頂端的頻率。
使用取樣方法剖析應用程式
以系統管理員權限開啟 Visual Studio。 程式碼剖析需要以系統管理員身分執行。
開啟 PeopleTrax 方案。
PeopleTrax 方案會填入 (Populate) [方案總管] 中。
請將專案組態設定為 [Release]。
您應該使用發行組建來偵測應用程式中的效能問題。 由於偵錯組建編譯時會插入額外資訊，可能對效能產生負面影響，而無法正確描述效能問題，因此建議您在剖析時使用發行組建。
按一下 [分析] 功能表上的 [啟動效能精靈]。
[效能精靈] 隨即出現。
確定已選取 [CPU 取樣 (建議使用)]，然後按 [下一步]。
在 [您要以哪一個應用程式做為分析的目標] 中，選取 PeopleTrax，然後按 [下一步]。
Visual Studio 會建置專案並開始剖析應用程式。 [PeopleTrax] 應用程式視窗隨即出現。
按一下 [Get People]。
按一下 [Export Data]。
[記事本] 便會開啟，並顯示包含從 [PeopleTrax] 匯出之資料的新檔案。
請關閉 [記事本]，然後關閉 [PeopleTrax] 應用程式。
分析工具會產生程式碼剖析資料 (*.vsp) 檔案，在 [效能總管] 視窗的 [報表] 區段中列出檔案名稱，並且在 Visual Studio 主視窗中自動載入資料檔案的 [摘要] 檢視。
若要分析取樣的剖析結果
[摘要] 檢視會顯示在執行程式碼剖析過程中 CPU 使用率的時間表、代表應用程式呼叫樹狀圖中最活躍分支的 [最忙碌路徑] 清單，以及執行函式主體中的程式碼時取得最多樣本之函式的 [執行最多個別工作的函式] 清單。
檢查 [最忙碌路徑] 清單，並且注意 PeopleNS.People.GetNames 方法是最接近清單結尾的 PeopleTrax 函式。 這個位置讓它成為分析的候選項。 按一下函式名稱，在 [函式詳細資料] 檢視中顯示 GetNames 的詳細資料。
[函式詳細資料] 檢視包含兩個視窗。 [成本分配] 視窗提供下列項目的圖形檢視：函式已完成的工作、它呼叫的函式已完成的工作，以及呼叫此函式之函式對取樣執行個體數目的比重。 您可以按一下函式名稱，變更檢視的焦點函式。 例如，您可以按一下 PeopleNS.People.GetPeople，讓 GetPeople 成為選取的函式。
[函式程式碼檢視] 視窗會在函式可使用時顯示其原始程式碼，並且反白顯示選取的函式中耗費最多資源的程式行。 選取 GetNames 時，您會發現這個函式從應用程式資源讀取字串，然後使用 StringReader 將字串中的每一行加入至 ArrayList。 沒有顯著方式可以最佳化這個函式。
因為 PeopleNS.People.GetPeople 是 GetNames 的唯一呼叫端，請按一下 [成本分配] 視窗中的 GetPeople，檢查其程式碼。 這個方法會從 GetNames 所產生的人員和公司名稱傳回 PersonInformationNS.PersonInformation 物件的 ArrayList。 不過，每次建立 PersonInformation 物件時會呼叫 GetNames 兩次。 您會發現只要在方法開頭建立清單一次，然後在 PersonInformation 建立迴圈期間在這些清單中索引，即可輕鬆最佳化方法。
在範例應用程式的程式碼中提供了 GetPeople 替代版本，您可以將條件式編譯符號加入至組建屬性來呼叫最佳化函式。 在 [方案總管] 視窗中，以滑鼠右鍵按一下 People 專案，然後按一下 [屬性]。 按一下屬性頁功能表上的 [建置]，然後在 [條件式編譯的符號] 文字方塊中輸入 OPTIMIZED_GETPEOPLE。 GetPeople 的最佳化版本就會在下次建置中取代原始方法。
重新執行效能工作階段。 在 [效能總管] 工具列上，按一下 [啟動並啟用程式碼剖析]。 按一下 [GetPeople]，然後按一下 [匯出資料]。 關閉出現的 [記事本] 視窗，然後關閉 PeopleTrax 應用程式。
隨即產生新的程式碼剖析資料檔案，而且新資料的 [摘要] 檢視會出現在 Visual Studio 主視窗中。
若要比較兩個程式碼剖析回合，請在 [效能總管] 中選取兩個資料檔案，以滑鼠右鍵按一下檔案，然後按一下 [比較效能報告]。 [比較報告] 視窗隨即出現在 Visual Studio 主視窗中。 [差異] 資料行會顯示函式效能值從先前 [基準] 值到後來 [比較] 值的變更。 您可以在 [資料行] 下拉式清單中選取要比較的值。 選取 [內含樣本 %]。
請注意，GetPeople 和 GetNames 方法會顯示相當多的效能增長。
使用檢測方法進行剖析
檢測是一種剖析方法，分析工具會在受檢測二進位檔的特殊建置版本中插入探查函式。 探查會收集受檢測模組中函式進入和離開以及這些函式內所有呼叫位置的時間資訊。 對於調查輸入/輸出作業相關問題如寫入磁碟和網路通訊，檢測程序很有用。 檢測比取樣提供更詳細的資訊，但在程序執行上更具侵入性並且發生更大量的額外負荷。 已檢測之二進位檔的大小也會比偵錯或發行的二進位檔來得大，所以並不適合用來部署。
在本節的逐步解說中，我們將使用檢測方法來探索先前剖析的 PeopleTrax 應用程式中可以最佳化的其他程式碼。 透過使用 [摘要] 檢視時間表的篩選，我們將集中分析在進行程式碼剖析的應用程式中將人員清單寫入 [記事本] 檔案的匯出資料情節。
若要使用檢測方法剖析現有的應用程式
必要時，在 Visual Studio 中開啟 PeopleTrax 應用程式。
確定您是以系統管理員身分執行，而且方案的組建組態已設為 [發行]。
在 [效能總管] 中，按一下 [檢測]。
在 [效能總管] 工具列上，按一下 [啟動並啟用程式碼剖析]。
分析工具就會建置專案並開始剖析應用程式。 PeopleTrax 應用程式視窗隨即出現。
按一下 [Get People]。
PeopleTrax 資料格會填入資料。
等候約 10 秒，然後按一下 [匯出資料]。
[記事本] 便會啟動並顯示新檔案，這個新檔案則包含從 [PeopleTrax] 匯出的人員清單。 等候可讓您更輕鬆識別要篩選的資料匯出程序。
請關閉 [記事本]，然後關閉 [PeopleTrax] 應用程式。
Visual Studio 便會產生一份效能工作階段報告 (*.vsp)。
若要分析檢測的剖析結果
報表的 [摘要] 檢視中的時間表圖形會顯示在執行程式碼剖析期間程式的 CPU 使用率。 匯出資料作業應該是圖形右側的高尖峰或高原。 我們可以篩選效能工作階段，只顯示及分析匯出作業中所收集的資料。 在圖形上，按一下匯出資料作業開始之資料點的左側。 再按一下作業的右側。 然後按一下時間表右側連結清單中的 [依選取範圍篩選]。
[最忙碌路徑] 樹狀圖顯示 PeopleTrax.Form1.ExportData 方法呼叫的 Concat 方法耗用大部分的時間。 因為 System.String.Concat 也是位於 [含有最多個別工作的函式] 清單的最上方，所以減少此函式所花費的時間是可能的最佳化地方。
在任一個摘要資料表中按兩下 [System.String.Concat]，查看 [函式詳細資料] 檢視中的詳細資訊。
您會發現 PeopleTrax.Form1.ExportData 是呼叫 Concat 的唯一方法。 按一下 [呼叫函式] 清單中的 [PeopleTrax.Form1.ExportData]，選取此方法做為 [函式詳細資料] 檢視的目標。
檢查 [函式程式碼檢視] 視窗中的方法。 請注意，並沒有 System.String.Concat 的常值 (Literal) 呼叫。 相反地，有數個地方使用 += 運算元，編譯器將其取代為 System.String.Concat 的呼叫。 在 .NET Framework 中對一個字串所做的任何修改，都會導致一個新字串受到配置。 這是因為 .NET Framework 含有 StringBuilder 類別，此類別會針對字串的串連進行最佳化。
若要以最佳化的程式碼取代這個有問題的區域，請將 OPTIMIZED_EXPORTDATA 以條件式編譯符號的方式加入至 PeopleTrax 專案。
在 [方案總管] 中，以滑鼠右鍵按一下 [PeopleTrax] 專案，然後按一下 [屬性]。
[PeopleTrax] 專案屬性表單隨即出現。
按一下 [建置] 索引標籤。
在 [條件式編譯的符號] 文字方塊中，輸入 OPTIMIZED_EXPORTDATA。
關閉專案屬性表單，並在提示時選擇 [全部儲存]。
當您再次執行應用程式時，便可見到顯著的效能改進。 雖然使用者能感覺到效能已有所改善，還是建議您再次執行剖析工作階段。 由於第一個問題可能會遮蔽其他問題，因此在修正問題後再檢閱資料是很重要的。