發行項
08/13/2015

本文章是由機器翻譯。

執行緒診斷

效能調整與並行 Visual Studio 2010 的視覺化檢視

多核心處理器已經成為廣泛可用，新的處理器中的單一執行緒效能很可能維持相當平面。也就是說在軟體開發人員來改善應用程式效能較佳運用平行處理原則上加入壓力。

平行程式設計因許多原因而是極具挑戰性，但本文中我喜歡將焦點放在平行應用程式的效能層面上。多執行緒應用程式並不只容易產生的循序的實作如效率不佳的演算法、不佳的快取行為及過多 I/O 的效率的通用來源，但它們也可以遭受平行效能 Bug。平行效能和延展性可能會受限於負載 imbalance、過度的同步處理負荷、不小心序列化或執行緒移轉。

瞭解由專家的開發人員使用要求明顯檢測和分析這類效能瓶頸。即使那些精銳的程式設計人員的效能調整已繁瑣且耗時的處理程序。

這是變更越好。 Visual Studio 2010 包含新的程式碼剖析工具 — 並行視覺化檢視 —，應能顯著降低平行效能分析的負擔。此外，並行視覺化檢視可以協助開發人員分析來探索的平行處理機會其循序應用程式。本文章中，我會提出連同一些實用的使用量指引的並行視覺化檢視，在 Visual 的 Studio 2010 功能的概觀。

CPU 使用

並行視覺化檢視包含數個視覺效果和報告工具。有三種主要檢視：CPU 使用量、執行緒，與核心。

圖 1 所示 [CPU 使用量檢視被要在並行視覺化檢視中的開始點。 x 軸顯示的耗用時間從追蹤開始到結束的應用程式的活動 (或追蹤結尾無論哪個都是較早)。 y 座標軸會顯示在系統中的邏輯處理器核心。

圖 1 CPU 使用量檢視

我將說明的檢視目的之前很重要您瞭解什麼是邏輯的核心。單一的 CPU 晶片今天可以包含多個的微處理器電路稱為實體的核心。每個實體的核心可能能夠同時執行多個應用程式執行緒。這通常稱為同時多執行緒處理 (SMT) ； Intel 呼叫它超執行緒技術。每個硬體支援的執行緒上 SMT 能夠核心呈現本身作為作業系統的邏輯核心。

當您在不支援 SMT 的四核心系統上收集追蹤，y 軸便會顯示四個邏輯的核心。如果您的四核心系統中每個核心是能夠執行兩個 SMT 執行緒，y 軸就會顯示八個邏輯的核心。這裡的點是邏輯的核心的數量同時可以在您的系統不實體核心的數量中執行的執行緒數目的反映。

現在，let’s 回到檢視。圖例中所述，有四個區域，在圖形所示。綠色區域所示範的是被分析應用程式使用在任何指定的時間期間程式碼剖析回合的邏輯核心的平均數量。其餘的邏輯的核心都是閒置 (以灰色顯示)，(如紅色中所示)，系統處理序所使用，或使用的 (如 [黃色] 所示) 系統上執行其他處理程序。

垂直的藍色列，在此檢視中對應到選用的機制，可以讓使用者以建立工具中的視覺效果相互關聯與應用程式建構檢測其程式碼。我將說明如何可以在本文稍後。

向左頂端的 [縮放] 滑桿控制可讓您拉近檢視，以取得更多詳細資料，並且圖表控制項支援水平捲軸縮放比例，當。您也可以按一下滑鼠左鍵並拖曳區域圖形本身中縮放。

這個檢視有三個主要用途。先，如果您興趣的平行處理應用程式就可以尋找區域執行的任一個展現顯著序列的 CPU 繫結工作，顯示為單核心的冗長綠色區域層級 y 軸或區域上有 isn’t 多 CPU 使用率的地方、綠色 doesn’t 顯示或平均是急遽小於 1 的地方。這兩個這些情況下可能表示平行處理的機會。需要大量 CPU 的工作可以被 sped 藉由運用平行處理原則，並區域未預期的低 CPU 使用率可能暗示封鎖 (也許因為 I/O) 可以藉由重疊其他有用的工作，以這種延遲使用平行處理原則。

第二個，如果您想要微調平行應用程式這個檢視可讓您確認當您的應用程式實際執行時存在的平行度。只要藉由檢查此圖形是通常明顯許多常見的平行效能 Bug 的提示。比方說，您可以觀察預期平行處理原則時，載入 imbalances 為圖表或爭用的同步處理物件為序列執行中的樓梯步驟模式。

第三，因為您的應用程式存留在執行許多其他競爭其資源的應用程式的系統，務必瞭解您的應用程式 ’s 效能會受到其他應用程式。當干擾意外時它通常是減少停用應用程式或服務，以改善資料，逼真度因為效能通常會反覆執行的處理程序是個不錯的作法。有時候，干擾是由應用程式合作來傳遞的經驗與其他處理程序所引起。不論是哪一種方式就可以使用此檢視來探索是否存在這類干擾，並然後識別使用我稍後會討論的 [執行緒] 檢視的 [實際相關處理程序。

可幫助減少干擾的另一項功能使用程式碼剖析工具命令列工具來收集追蹤，而不是這種方式從 Visual Studio IDE 中。

把焦點放您的注意 piques 您感興趣的執行的一些視窗上、拉近它，然後切換至 [執行緒檢視，供進一步的分析。您可以隨時回到此檢視來尋找下一個感興趣的區域，並重複此程序。

執行緒

圖 2 中顯示 [執行緒檢視包含大量的詳細的分析功能和並行視覺化檢視中的報表。這是您在其中找到說明的行為 CPU 使用量或核心檢視中識別的資訊。它也是您可以在其中找到資料，以連結至應用程式的原始程式碼儘可能的行為。有此檢視的三個主要元件：時間軸、使用中的圖例和報告/詳細資料] 索引標籤控制項。

與 CPU 使用量] 檢視類似 [執行緒檢視會顯示時間 x 軸上。 (當並行視覺化檢視中的檢視之間切換的 x 軸上顯示的時間範圍會保留)。不過，執行緒檢視 y 軸會包含兩種類型的水平的頻道。

頂端通道是通常是專門用來在您的系統上的實體磁碟] 中，如果它們有應用程式 ’s 設定檔中的活動。有兩個通道每個各一讀取和寫入磁碟。這些頻道顯示您的應用程式執行緒或系統處理序的執行緒所做的磁碟存取。 (它顯示系統存取因為它們有時可以反映運作的這類的分頁您程序做)。每個讀取或寫入繪製為一個矩形。矩形的長度描述的延遲包括佇列的「存取延遲；因此，多個矩形可能會重疊。

若要判斷哪些檔案已在指定的點存取時間，請按一下滑鼠左鍵來選取矩形。當您執行的這項下面的 [報告] 檢視將會切換是標準的位置，可顯示的資料與時間軸以互動方式 [目前的堆疊] 索引標籤。其內容將會列出已 [讀取] 或依上選取的磁碟通道寫入的檔案名稱。我會稍後傳回 I/O 分析。

一件事要注意的是不是所有的檔案讀取，而應用程式所執行的寫入作業可能會看到當預期會發生。這是因為作業系統 ’s 檔案系統會使用緩衝處理允許某些磁碟 I/O 作業完成而不存取實體磁碟裝置。

在時間表上剩餘的頻道列出存在於您的應用程式設定檔集合期間內的所有執行緒。針對每個執行緒如果工具在程式碼剖析工具] 執行期間偵測到任何活動它就會顯示整個追蹤執行緒的狀態直到它終止。

如果執行緒正在執行，依綠色執行類別所描述的並行視覺化檢視會顯示您在執行緒已利用範例設定檔資訊執行哪些動作。有兩種方法，以取得此資料。其中一個是綠色的區段上按一下，在這種情況下則查看最接近 (內 + /-1 ms) 在目前的堆疊] 索引標籤視窗中的設定檔範例呼叫堆疊。

您也可以產生範例設定檔報表看得見的時間範圍內，以瞭解花費大部份的工作了。如果按一下在作用中的圖例中的 [執行] 標籤報表會顯示在 [基本資料報表] 索引標籤中。設定檔報表，有可能用來降低複雜度的兩個功能。其中之一是噪音縮減的一項功能，預設移除呼叫堆疊負責 2%或以下的設定檔範例。使用者可以變更此臨界值。另一個稱為 Just My Code 的功能可用來減少因為到報表中的系統 DLL 的堆疊框架數量如果的 ’s 令人滿意。我涵蓋中更詳細的報告。

在繼續，之前先我喜歡點出幾個更多的功能，用於管理報告和檢視表中的複雜性。您時常會遇到其中某些可能不會進行動作在給定的分析工具執行有用的許多執行緒所組成的應用程式案例。除了篩選依據時間範圍內的報表，並行視覺化檢視也可以讓您以篩選出作用中的執行緒。如果 ’re 興趣執行工作的執行緒，您可以使用 [排序依據] 選項來排序執行緒它們是在執行狀態的時間百分比。您可以再選取執行緒，不做很多有用的工作上按一下滑鼠右鍵，並從內容功能表選取 [隱藏] 選項或按一下頂端的檢視工具列中的 [隱藏] 按鈕從顯示隱藏這些的群組。您可以所有執行緒狀態分類排序，並取消都可以隱藏/隱藏時，請參閱符合。

隱藏執行緒效果是所有報告其貢獻將會移除，除了隱藏時間表從其通道。所有統計資料和報表中的工具會保持最新狀態，以動態方式為在執行緒和時間範圍上執行的篩選。

封鎖類別

因許多原因而可以封鎖執行緒。執行緒檢視會試著識別為什麼執行緒封鎖藉由對應到一組的封鎖類別的每個執行個體的原因。我說的嘗試，因為此分類可以有時會不正確，我因此應概略指南以檢視說明中一個一點時間。話雖如此，執行緒檢視會顯示所有執行緒延遲，並準確地描述執行期間。您的注意應該注重類別負責嚴重的延遲，在檢視中根據您對應用程式 ’s 行為的瞭解。

在另外執行緒檢視會提供呼叫堆疊的執行緒停止目前的堆疊] 索引標籤中的執行如果您按一下 [封鎖的事件。按一下 [在目前的堆疊] 視窗中的堆疊框架上，使用者將會採取至原始程式檔 (若有提供) 和行號呼叫下一個的函式。這是工具的一項重要的產能功能。

let’s 看看不同的封鎖類別：

同步處理 幾乎所有的封鎖作業可以是屬性化至 Windows 中的基礎的同步處理機制。並行視覺化檢視會試著將因為要同步處理如 EnterCriticalSection 和 WaitForSingleObject API 封鎖事件對應至這個類別，但有時候可能在內部導致同步處理其他作業對應到此類別 — 即使它們可能會讓更多意義其他地方。因此，這是通常非常重要的封鎖類別，以分析期間效能調整，不只是因為同步處理投影片重要但也因為它可以反映執行延遲的其他重要的原因。

preemption 執行緒 ’s 共用上的核心時間到期時，這包括 preemption 限於配量到期。它也包括 preemption 限於 OS 排程如具有較高的優先順序是準備好執行另一個處理序執行緒的規則。並行視覺化檢視也會對應 preemption 這裡，例如插斷及 LPCs 而導致中斷執行緒 ’s 執行其他來源。在這類每個事件，使用者可以取得處理序識別碼/名稱和執行緒花了透過滑鼠停留 preemption 地區，檢查工具提示的 ID (或按一下 [上一個黃色的區域和觀察目前堆疊] 索引標籤的內容)。這可以是一有價值的功能，可瞭解的 CPU 使用量檢視中的黃色干擾根原因。

睡眠狀態 此類別用來報告由執行緒要睡眠狀態或自願產生的核心執行緒封鎖事件的明確要求的結果。

分頁/記憶體管理 此類別涵蓋封鎖事件由於記憶體管理包括應用程式所啟動的系統 ’s 記憶體管理員做為回應給某個動作任何封鎖作業。事情喜歡某些記憶體配置爭用式分頁錯誤或封鎖特定資源就會出現這裡。分頁錯誤特別的是值得注意，因為它們可能會導致 I/O。當您看到封鎖  event 分頁錯誤時，您應該同時檢查呼叫堆疊，尋找對應的 I/O 讀取磁碟通道上的事件，以免分頁錯誤所需的 I/O。這類的分頁錯誤的常見來源正在載入 DLL、記憶體對應 I/O 和一般由核心的虛擬記憶體分頁。您可以識別這是 [按一下到取得檔名牽涉到對應的 [I/O] 區段上的 [DLL 載入還是分頁。

I/O 此類別包括的事件，例如封鎖檔案讀取及寫入、特定的網路通訊端作業和登錄存取。此，但而是在同步處理類別，可能不會顯示被視為由某些被網路相關的作業數目。這是因為許多 I/O 操作使用同步處理可能不在此類別中那些 API 簽章尋找區塊和並行視覺化檢視的機制。就像與記憶體/分頁] 分類看到似乎存取您的磁碟磁碟機與相關的 I/O 封鎖事件時您應該找出是否有 ’s 對應的磁碟存取磁碟通道中。這讓更容易，您可以使用在工具列上箭號按鈕將使其更靠近您的執行緒移到磁碟通道。來執行這項操作，按一下它在左邊的標籤上的 [選取執行緒通道，然後按一下適當的工具列按鈕上。

使用者介面處理 這是唯一的形式封鎖是通常令人滿意。它是執行緒的激發訊息的狀態。如果您的 UI 執行緒也需要花費最多時間在此狀態，這暗示著您的應用程式是有回應。在另一方面，如果 UI 執行緒不會過多工時或因為其他原因封鎖，從應用程式使用者 ’s 觀點來看 UI 將會出現停止回應。此類別提供絕佳的方法研究應用程式的回應速度，並調整它。

inter-thread 相依性

最有價值的功能，執行緒檢視之一是能夠判斷 inter-thread 同步相依性。的 圖 2 中我已選擇同步處理延遲區段。將區段取得放大，而其色彩反白顯示 (在這種情況下它 ’s 紅色)。 [目前的堆疊] 索引標籤會顯示在該執行緒的呼叫堆疊。在測試呼叫堆疊中，您可以判斷導致封鎖執行緒 ’s 執行的 API。

圖 2 的 執行緒檢視

另一種視覺效果功能是將封鎖區段連接到不同的執行緒上將執行線段的線條。當這個視覺效果顯示時，它說明了最後解除封鎖已封鎖的執行緒的執行緒。在另外您可以按一下 [Unblocking 堆疊] 索引標籤上在這種情況下以查看解除封鎖的執行緒時釋放已封鎖的執行緒已經執行的動作。

做為範例如果封鎖執行緒等候 Win32 關鍵區段就會看到 EnterCriticalSection 的簽名碼在其封鎖的呼叫堆疊上。當是解除封鎖您應該會看到解除封鎖執行緒的呼叫堆疊中的 LeaveCriticalSection 簽章。分析複雜的應用程式行為時，這項功能可能會非常有價值。

報告

設定檔報告提供簡單的方法，識別您的應用程式的效能行為的主要參與者。是否您感興趣執行投影片]、 [封鎖的投影片] 或 [磁碟 I/O，這些報告可以讓您專注於最大顯著性可能是值得研究的項目。

有四種執行緒檢視中的報告：執行取樣設定檔，封鎖設定檔，檔案作業和每個執行緒的摘要。所有報表是使用圖例進行都存取。比方說去執行設定檔報表按一下執行圖例該項目。這會產生基本資料報表] 索引標籤中的某一報表。報表看起來類似的 圖 3 中會顯示的內容。

圖 3 的一般設定檔] 報表

如未執行設定檔] 報表中，並行視覺化檢視會分析所有呼叫堆疊收集時取樣應用程式 ’s 執行 (綠色區段) 和 collates 藉由識別共用的堆疊框架，以協助使用者瞭解應用程式的執行結構。工具也會計算每個框架的 (含) 和獨佔成本。內含樣本負責在給定的執行路徑包括其下的所有路徑中的所有範例。專有樣本對應到的呼叫圖形堆疊框架樹葉的樣本數。

若要封鎖的設定檔您按一下圖例中的利息中的 [封鎖] 分類。產生的報告建構像執行設定檔報表，但 [內含] 和 [獨佔] 欄現在會對應到封鎖的時間使用屬性的呼叫堆疊或在報表中的框架。另一個資料行顯示封鎖的執行個體的屬性設定在呼叫樹狀圖中，堆疊框架。

這些報告提供方便 prioritizing 效能微調努力藉由識別的應用程式負責大部分延遲組件。 preemption 報表是資訊性，通常不提供任何可採取行動資料，因為此類別的本質。所有報表可都讓您跳至原始程式碼。您可能感興趣的堆疊框架上按一下滑鼠右鍵，執行這項作業。會出現快顯功能表可讓您跳至函式定義 ([檢視原始檔] 選項)，或位置，在您的應用程式中該函式被呼叫 (檢視呼叫站台選項)。若了多個呼叫端會顯示具有多個選項。這可讓診斷資料與開發程序來調整您的應用程式 ’s 行為之間的緊密地整合。報表可能也會匯用於交叉設定檔比較出。

包含所有檔案的摘要中 圖 4 所示的檔案操作報表的讀取和寫入作業在目前的時間範圍中可見。每個檔案的並行視覺化檢視列出應用程式存取它讀取的數目的執行緒，並寫入作業，總共的位元組讀取或寫入，與總讀取或寫入延遲。除了顯示給應用程式使用直接屬性的檔案作業，並行視覺化檢視也會顯示那些由系統處理程序執行。這些會顯示，如前所述，因為它們可能包含由系統來執行為您的應用程式的檔案作業。匯出報表期間調整努力讓交叉設定檔比較。

圖 4 的 檔案操作報表

圖 5 所示每一執行緒摘要報表呈現每個執行緒的長條圖。列分為不同的執行緒狀態類別。這可以是一個有用的工具來追蹤您調整進度的效能。跨各種微調反覆項目，匯出圖形資料，可以記錄您的進度，並提供比較回合的方法。圖表不會顯示有符合在檢視中的執行緒太多的應用程式的所有執行緒。

圖 5 每一執行緒摘要報告

核心

過多內容切換呈淚不方便的效果，對應用程式效能，尤其是將遷移執行緒跨核心或處理器通訊端，但它們繼續執行。這是因為執行中的執行緒會載入指示和 (通常稱為工作集) 它所需的資料到快取階層架構。當一個執行緒繼續特別是在另一個核心上的執行它可以降低明顯的延遲，雖然其工作集從記憶體或其他快取重新載入系統中。

有一般兩種方法可以減少此額外負荷。開發人員可以可能降低內容參數頻率解決基礎的原因或他可以運用處理器或核心相關性。先前幾乎都是多令人滿意，因為使用執行緒相似性可以是其他效能問題的來源，應該只用於在特殊情況下。核心檢視是一種工具，可協助識別過度內容切換或執行緒相似性所引入的效能 Bug。

做為與其他檢視，[核心檢視會顯示以時間時刻表 x 軸上。在 y 軸上顯示邏輯的核心系統中。應用程式中的每個執行緒會配置一個色彩，繪製核心通道，執行緒執行區段。的 圖 6 所示下方] 窗格會顯示圖例和內容的切換參數統計資料。

圖 6 的 核心檢視

統計資料可協助使用者識別有過多內容切換和那些造成過多核心遷移的執行緒。使用者可以使用此檢視來把焦點放在有問題的執行緒會中斷的位置，或在核心之間來回跳藉由遵循視覺化色彩提示執行中的區域她注意。一旦識別描述問題的區域，使用者可以拉近它，然後切換回 [執行緒] 檢視中，以了解什麼觸發內容切換，並修正它們可能的話 (比方說藉由減少爭用重要區段)。執行緒相似性 Bug 可以也資訊清單本身在某些情況下當兩個或多個執行緒爭用單一核心雖然其他核心似乎是閒置。

對於 PPL、 TPL 和 PLINQ 的支援

並行視覺化檢視支援平行的程式設計模型，在 Visual Studio 2010 運送除了從現有 Windows 原生和 Managed 程式設計模型。一些新的平行建構 — parallel_for 中 [平行圖樣程式庫 (PPL)，Parallel.For 工作平行程式庫 (TPL) 和 PLINQ 查詢中 — 納入效能工具，可讓您把焦點放在這些區域執行您注意的視覺輔助工具。

PPL 需要打開追蹤功能，才能啟用此功能，如這個範例所示：

Concurrency::EnableTracing();
parallel_for (0, SIZE, 1, [&] (int i2) {
  for (int j2=0; j2<SIZE; j2++) {
    A[i2+j2*SIZE] = 1.0;
    B[i2+j2*SIZE] = 1.0;
    C[i2+j2*SIZE] = 0.0;
  }
});
Concurrency::DisableTracing();

啟用追蹤時 [執行緒] 和 [核心檢視將會藉由繪製垂直標記在開頭和結尾，其執行的描繪 parallel_for 執行區域。垂直列都會透過水平列頂端及底部的檢視連線。藉由使用滑鼠停留水平列，顯示建構的名稱的工具提示會繪製，的 圖 7 所示。

圖 7 的 一個範例 parallel_for Visual 標記，在 [執行緒檢視

TPL 和 PLINQ 不需要手動啟用相等的功能，在並行視覺化檢視中的追蹤。

正在收集設定檔

並行視覺化檢視支援應用程式啟動，並附加收集設定檔的方法。行為是完全相同如 Visual Studio Profiler 使用者慣用以。新的程式碼剖析工作階段可能會啟始透過分析] 功能表選項，啟動示 圖 8 效能精靈，或透過分析工具 | 新增效能工作階段選項。在這兩種情況下並行視覺化檢視就會啟動選擇並行程式碼剖析方法，然後選取「視覺效果的多執行緒應用程式行為」選項。

圖 8 [效能精靈分析方法] 對話方塊

Visual Studio Profiler ’s 命令列工具可讓您收集並行視覺化檢視追蹤和分析他們使用 IDE。這可讓使用者興趣其中安裝 IDE 是不可能的伺服器案例中收集與最小的可能入侵的追蹤。

您會注意到並行視覺化檢視沒有程式碼剖析的 ASP.NET 應用程式的整合式的支援。不過，或許可以附加至主機處理序 (通常 w3wp.exe) 時執行 ASP.NET 應用程式來分析其效能。

由於並行視覺化檢視會使用事件追蹤的 Windows (ETW)，它需要系統管理權限，才能收集資料。您可以任一個啟動 IDE，以系統管理員或系統會提示您要執行這項操作，在必要時。在後者的情況下具有系統管理員權限將會重新啟動 IDE。

連結至應用程式階段的視覺效果

並行視覺化檢視中的另一個功能是選擇性的檢測程式庫，可以讓開發人員藉由繪製標記它們在意的應用程式階段的自訂檢視。這可以是非常珍貴，若要允許更容易視覺效果和應用程式行為之間的相互關聯。檢測文件庫稱為案例文件庫，可供從 code.msdn.microsoft.com/scenario 在 MSDN 程式碼庫 Web 網站下載。這裡 ’s 使用 C 的應用程式範例：

#include "Scenario.h"
int _tmain(int argc, _TCHAR* argv[]) {
  myScenario = new Scenario(0, L"Scenario Example", (LONG) 0);
  myScenario->Begin(0, TEXT("Initialization"));

  // Initialization code goes here

  myScenario->End(0, TEXT("Initialization"));
  myScenario->Begin(0, TEXT("Work Phase"));

  // Main work phase goes here  

  myScenario->End(0, TEXT("Work Phase"));
  exit(0);
}

使用方式是很簡單；您包含分析藍本標頭檔，並且將正確的程式庫連結。然後您可以建立一或多個分析藍本物件和Mark開頭與結尾的每個階段藉由叫用 [開始，分別結束方法。您也會指定每個階段，這些方法的名稱。視覺效果相當 圖 7 中顯示的不同之處在於工具提示會顯示在您的程式碼中指定的自訂階段名稱。在另外案例標記也會顯示在 [CPU 使用量] 檢視不符合上述情況的其他標記。同時也提供對等的 Managed 的  implementation。

注意的一個字是以此處的順序。案例標記應該盡量不要用；否則視覺效果可以完全被遮住它們。在實際上若要避免這個問題，工具將會大幅減少或消除如果偵測到過多的使用方式顯示的標記數目。在這種情況下可以拉近，以公開 elided 大部分檢視中的標記。進一步的分析藍本標記巢狀發生時就會顯示最內層的標記。

資源和錯誤

並行視覺化檢視包含許多功能，可以幫助您了解其檢視及報表。最有趣的這類功能是 Demystify 按鈕右上角的所有檢視] 所示。即可 Demystify 您取得特殊的滑鼠指標，讓您可以按一下任何功能上檢視中您上喜歡說明。這是我們提供工具中的即時線上說明的方法。

在另外有 ’s 秘訣定位點與更多的說明內容包括一些常見的效能問題的視覺效果簽章的組件庫的連結。

稍早提到工具會運用 ETW。某些所需的並行分析器事件上不存在 Windows XP 或 Windows Server 2003 讓工具僅支援 Windows Vista、 Windows Server 2008、 Windows 7 及 Windows Server 2008 R2。支援這些作業系統的 32 位元和 64 位元變種。

在另外工具支援兩個原生 C/C + + 和.NET 應用程式 (排除.NET 1.1 或更早版本)。如果您不在受支援的平台上執行，應該探索 Visual 選取「收集資源爭用資料」] 選項會啟用的 Studio 2010 中的另一個有價值的並行存取工具。

在某些情況下時有 ’s 大量的活動在程式碼剖析的案例中，或從其他應用程式的 I/O 頻寬的爭用時很重要的追蹤事件可能會遺失。這在追蹤分析時產生錯誤。有兩種方式來處理這種情況。先，您可以嘗試進行程式碼剖析一次與較小的數個作用中應用程式也就遵循以減少干擾，當您調整您的應用程式時的好方法。命令列工具會在這種情況下是額外的選項。

第二個，您可以增加數字或 ETW 記憶體緩衝區的大小。我們如何完成這項作業提供透過指示的 [輸出] 視窗中連結的文件。如果您選擇 [二] 選項請將最小的總緩衝區大小設定需要收集好的追蹤，因為這些緩衝區會消耗使用中的重要核心資源。

任何的診斷工具才好它提供給使用者的資料。並行視覺化檢視可以幫助您找出根本原因的效能問題的來源程式碼的參考，但為了要執行這項操作，它需要的符號檔案的存取權。您可以加入符號伺服器和路徑在 IDE 中使用 [工具 | 選項 | 偵錯 | 符號] 對話方塊。您目前的方案的符號將會隱含地包含，但是您應該啟用 Microsoft 公用符號伺服器，以及任何其他是針對受研究應用程式可以找到重要的符號檔的路徑。它也 ’s 啟用符號快取，因為，大幅會減少設定檔分析時間，如快取取得填入您需要的符號檔案是個不錯的作法。

雖然 ETW 提供了低負荷追蹤機制但可能會大並行視覺化檢視所收集到的追蹤。分析大型追蹤可以是非常耗時，而且可能會導致效能工具所提供的視覺效果中的投影片。通常，設定檔應該收集工期不超過一到兩分鐘的時間會影響您的經驗這些問題的機會降至最低。對於大多數的分析案例該工期是足夠識別問題。能力附加至執行中的處理序是為了要避免收集資料，您的應用程式到達感興趣的點之前也重要的功能。

有多個來源的並行視覺化檢視的資訊。請瀏覽 Visual Studio Profiler 論壇 ( social.msdn.microsoft.com/forums/en-us/vstsprofiler/threads ) 以取得社群和開發小組的答案。使用從小組部落格，在 blogs.msdn.com/visualizeparallel 和我個人的部落格，在 blogs.msdn.com/hshafi 進一步的資訊。請隨意若有任何有關我們工具的問題，到達我或我的小組。我們愛使用並行存取] 視覺化檢視的人的聽覺及您的輸入協助我們改進此工具。

Dr。 Hazim Shafi 是平行的效能和正確性工具架構設計師在平行運算平台小組在 Microsoft 中。他在平行和分散式運算和效能分析的許多方面有 15 年的經驗。他會保留一個 B.S.E.E. 從聖 Clara 大學和 M.S. 和博士從 Rice 大學度。

感謝到下列的技術專家來檢閱這份文件： Drake Campbell, Bill Colburn, Sasha Dadiomov 和 James Rapp