如今制造商們廣泛提供了多核心處理器，新處理器中的單線程性能相對而言可能就顯得平淡無奇了。那就意味著，對軟件開發人員來說，通過更好地利用並行機制來提高應用程序性能的壓力就更大了。
並行編程是一項很有挑戰性的工作，其原因很多，但我在本文中只想將重點放在並行應用程序的性能方面。多線程應用程序不止容易成為順序實現低效率進行（如低效的算法、低速的緩存行為、過多的 I/O）的常見原因，而且還可能具有並行性能 Bug。並行性能和可伸縮性可能受到負載不平衡、同步開銷過大、無意的序列化或線程遷移限制。
過去，要了解這樣的性能瓶頸，需要專家級開發人員進行大量的檢測和分析。即使是程序員中的佼佼者，性能優化也是一個枯燥而耗時的過程。
這種情況應該得到改善了。Visual Studio 2010 中包含了一個新的分析工具：Concurrency Visualizer，它可大大減輕並行性能分析工作的負擔。此外，Concurrency Visualizer 還能幫助開發人員分析其順序應用程序，以發現並行執行這些應用程序的可能性。在本文中，我將概括介紹 Visual Studio 2010 中 Concurrency Visualizer 的功能，並給出一些實踐上的使用指導。
CPU 利用率
Concurrency Visualizer 中包含幾個可視化和報告工具。有三個主要視圖：分別是“CPU 利用率”、“線程”和“核心”視圖。
圖 1 中顯示的“CPU 利用率”視圖是開始使用 Concurrency Visualizer 的位置。X 軸顯示從跟蹤開始時起，到應用程序活動結束或跟蹤結束這兩個時刻中的較早時刻止，所經過的時間長度。Y 軸顯示了系統中邏輯處理器核心的數量。
圖 1 “CPU 利用率”視圖
在我開始描述該視圖的用途之前，您需要了解什麼是邏輯核心，這很重要。如今的單個 CPU 芯片可能包括多個微處理器電路，這些電路即稱為“物理核心”。每個物理核心可能能夠同時運行多個應用程序線程。這通常稱為多線程並行處理 (SMT)；Intel 稱它為“超線程技術”。可進行 SMT 處理的核心上每個受硬件支持的線程都向操作系統將自己呈現為一個邏輯核心。
如果在不支持 SMT 的四核心的系統上收集跟蹤數據，則 Y 軸將顯示 4 個邏輯核心。如果四核心系統中的每個核心都能夠運行兩個 SMT 線程，則 Y 軸將顯示 8 個邏輯核心。這裡的重點是，邏輯核心數是對可並發在系統中執行的線程數的反映，而不是對物理核心數的反映。
現在，讓我們再來討論視圖。如圖例中所述，圖中顯示了四個區域。綠色區域描述在分析運行過程中的給定時間，所分析的應用程序使用的平均邏輯核心數。其余邏輯核心處於空閒狀態（以灰色顯示）、由系統進程使用（以紅色顯示）或由系統上運行的其他進程使用（以黃色顯示）。
此視圖中的藍色豎條對應於一個可選的機制，用戶可用該機制來檢測其代碼，以將工具中的可視化內容與應用程序構造關聯起來。我將在本文中稍後的部分解釋如何執行這些操作。
左上方的“放大”滑塊控件可用於放大視圖，以查看更多詳細信息，放大後，圖形控件提供水平滾動條支持。也可單擊鼠標左鍵並拖動圖形本身中的區域來放大視圖。
此視圖有三個主要用途。首先，如果您對並行化應用程序感興趣，則可以尋找執行區域，這些區域展示占用很多 CPU 資源的大量串行工作（在 Y 軸上的單核心級別顯示為長長的綠色區域），或是 CPU 利用率不高的區域（這種區域中不顯示綠色或平均利用率比 1 小得多）。這些情況都可能代表了實現並行化的機會。通過利用並行機制可加速執行頻繁使用 CPU 的工作，如果區域顯示 CPU 利用率出人意料地低，則可能暗示存在堵塞情況（可能由於 I/O 造成），這種情況下，可在這樣的延時期間重疊執行其他有用的工作，從而實現並行運行。
第二，如果您在嘗試優化並行應用程序，則可在應用程序實際運行時通過此視圖確認並行程度如何。一般來說，只需查看此圖，就可明顯發現許多常見的並行性能 Bug。例如，您可能在該圖中看到以階梯狀表示的負載不均衡情況，或者看到在本應並行執行時發生串行執行以致造成同步對象爭用。
第三，由於在您的應用程序所在的系統中，還有很多其他的應用程序在執行時要爭用系統資源，因此，了解您的應用程序的性能是否受其他應用程序影響非常重要。如果這種干擾是您不希望看到的，則禁用應用程序或服務以提高數據的保真度通常是個減少干擾的好辦法，因為性能通常是迭代變化的。有時，干擾是由其他進程導致的，您的應用程序為提供使用體驗而要與這些進程協作。無論是哪一種情況，您都能夠使用此視圖發現是否存在干擾，然後使用我將在後面討論的“線程”視圖來識別實際涉及到的進程。
另一項可以幫助減少干擾的功能是使用探查器命令行工具來收集跟蹤數據，而不是從 Visual Studio IDE 中收集。
將您的注意力放在引起您的興趣的某個執行窗口上，將其放大，然後切換到“線程”視圖以進一步進行分析。您隨時可以返回到此視圖，找到您感興趣的下一個區域，並重復此過程。
線程
在圖 2 中顯示的“線程”視圖中包含 Concurrency Visualizer 中的大部分詳細分析功能和報告。您將在此視圖中找到能解釋在“CPU 利用率”或“核心”視圖中所看到的行為的信息。您還可在此視圖找到數據，以便在可能的情況下將行為與應用程序源代碼關聯起來。此視圖有三個主要組成部分：時間線、活動圖例和報告/詳細信息選項卡控件。
就像“CPU 利用率”視圖一樣，“線程”視圖在 X 軸上顯示時間。（在 Concurrency Visualizer 中在視圖之間進行切換時，顯示在 X 軸上的時間范圍保持不變。）但是，“線程”視圖的 Y 軸包含兩種水平通道。
頂部通道通常專用於系統上在您的應用程序分析中有活動的物理磁盤。每個磁盤有兩個通道，一個用於讀取，另一個用於寫入。這些通道顯示您的應用程序線程或系統進程線程進行的磁盤訪問。（它顯示系統訪問，因為有時這樣的訪問可以代表進程反映正在進行的工作，如分頁。）每一個讀取或寫入操作都繪制為一個矩形。矩形的長度描述訪問的延遲時間，包括排隊延遲，因此，多個矩形可能會重疊。
若要確定在給定時刻訪問了哪些文件，請單擊鼠標左鍵選擇一個矩形。選擇時，下方的報告視圖將切換到“當前堆棧”選項卡，這是用於通過時間線交互顯示數據的標准位置。該選項卡中將列出被讀取或寫入的文件的名稱，具體列出何種文件名取決於所選的磁盤通道。我將稍後再來討論 I/O 分析。
您要知道，應用程序執行的所有文件讀寫操作不一定都會在發生時顯示出來。這是因為操作系統的文件系統使用緩沖機制，因此一些磁盤 I/O 操作無需訪問物理磁盤設備就可完成。
時間線中的其余通道將列出在分析數據收集期間存在於應用程序中的所有線程。對於每個線程，如果工具檢測到在探查器運行期間有任何活動，它就會在整個跟蹤過程中顯示該線程的狀態，直至線程終止。
根據綠色“執行”類別的描述，如果某個線程正在運行，則 Concurrency Visualizer 會顯示該線程利用樣本分析信息在執行的操作。有兩種方法可以獲得此數據。一種方法是單擊綠色段，這時您將在“當前堆棧”選項卡窗口中看到最近的（在一毫秒浮動范圍內）分析樣本調用堆棧。
還可以生成可見時間范圍的樣本分析報告，以了解大部分工作將時間花費在何處。如果單擊活動圖例中的“執行”標簽，則報告將顯示在“分析報告”選項卡中。分析報告有兩個功能可用於減小復雜度。一個是降噪功能，默認情況下，該功能會移除生成分析樣本 2% 或更少比率的調用堆棧。用戶可更改此阈值。另一個功能稱為“僅我的代碼”，如果需要，可用於減少報告中系統 DLL 導致的堆棧幀的數量。我將在稍後更詳細地討論這些報告。
在繼續說明之前，我想指出另外幾個用於管理報告和視圖中復雜度的功能。您將經常遇到包含很多線程的應用程序場景，其中一些線程在給定探查器運行時可能沒有執行任何有用的工作。除了基於時間范圍過濾報告之外，還可在 Concurrency Visualizer 中按活動線程進行過濾。如果您對真正執行工作的線程感興趣，可使用“排序依據”選項按線程處於“執行”狀態的時間百分比來將線程排序。然後可選擇沒有執行很多有用工作的線程組，單擊右鍵並從上下文菜單中選擇“隱藏”選項，或單擊視圖頂部工具欄中的“隱藏”按鈕來隱藏這些線程。可以按所有線程狀態類別進行排序，還可根據您的需要隱藏/顯示線程。
隱藏線程的影響就是，除了在時間線上隱藏其通道之外，在所有報告中都不會再反映出它們的作用。對線程和時間范圍執行過濾時，該工具中的所有統計數據和報告都會動態變化，以保持最新。
阻塞類別
線程可能由於很多原因而阻塞。“線程”視圖會將每個實例歸到一組阻塞類別，以嘗試標識線程阻塞的原因。我之所以說“嘗試”，是因為這種分類有時可能不准確（我稍後會對此進行說明），因此應該將它視作粗略的指南。即便如此，“線程”視圖會顯示所有的線程延遲並准確描述執行期間。您應該基於您對應用程序行為的了解，將注意力集中在視圖中導致重大延遲的類別上。
此外，如果您單擊阻塞事件，“線程”視圖會在“當前堆棧”選項卡中提供線程停止執行時所在的調用堆棧。用戶單擊“當前堆棧”窗口中的堆棧幀，就可查看源代碼文件（如果有）和將調用下一個函數的行號。這是該工具的一項能體現效率的重要功能。
讓我們來看一下不同的阻塞類別：
同步：幾乎所有的阻塞操作都可歸因於 Windows 中的底層同步機制。Concurrency Visualizer 嘗試將由於同步 API（如 EnterCriticalSection 和 WaitForSingleObject）而造成的堵塞事件歸為此類別，但是有時在內部導致同步的其他操作可能也會歸為此類別，即使這些事件可能在別處有意義也是如此。因此，這通常是要在性能優化過程中進行分析的非常重要的堵塞類別，這不僅是因為同步開銷很重要，還因為該類別可反映出導致執行延遲的其他重要原因。
搶占：這包括由於線程超出在其核心上的時間份額導致的搶占。這還包括由於操作系統計劃規則導致的搶占，如另一個具有較高優先級且准備好運行的進程線程的搶占。Concurrency Visualizer 還會在此處列出導致搶占的其他原因，如中斷和 LPC，這些原因可能導致線程執行被中斷。在每次發生這樣的事件時，用戶都可將鼠標懸停在搶占區域並查看工具提示，或單擊黃色區域並觀察“當前堆棧”選項卡的內容，從而獲取接管進程 ID/名稱和線程 ID。要了解“CPU 利用率”視圖中黃色干擾的根本原因，這可能是很有價值的一個功能。
睡眠：此類別用於報告因線程顯式請求睡眠或顯式請求自動放棄對其核心的使用權而導致的線程阻塞事件。
分頁/內存管理：此類別包括由於內存管理導致的阻塞事件，其中包括系統的內存管理器為響應應用程序所執行的操作而啟動的所有阻塞操作。像頁面錯誤、某些內存分配爭用或某些資源的阻塞之類的事件都會顯示在此處。頁面錯誤尤其值得注意，因為這種錯誤可能導致 I/O。看到頁面錯誤阻塞事件時，您不但應該檢查調用堆棧，還應在磁盤通道上查找相應的 I/O 讀取事件，以防頁面錯誤需要 I/O。這種頁面錯誤的常見原因是內核所執行的加載 DLL、內存映射 I/O 和正常的虛擬內存分頁等操作。單擊相應的 I/O 段獲取所涉及的文件名，便可確定這是 DLL 加載還是分頁。
I/O：此類別包括執行諸如文件讀寫、某些網絡套接字操作以及注冊表訪問之類的操作時發生的阻塞事件。一些人認為與網絡有關的一些操作可能不會在此處顯示，而是在 “同步”類別中顯示。這是因為很多 I/O 操作都使用同步機制進行阻塞，而 Concurrency Visualizer 可能不在此類別中尋找那些 API 簽名。就像“內存/分頁”類別一樣，當您看到看起來與訪問磁盤驅動器有關的 I/O 阻塞事件時，您應該在磁盤通道中查明是否存在相應的磁盤訪問。為使此操作變得更為簡單，可以使用工具欄中的箭頭按鈕將線程移到更接近磁盤通道的位置。為此，請單擊某個線程通道左側的標簽選擇該通道，然後單擊相應的工具欄按鈕。
UI 處理：這是人們通常認為合理的唯一一種阻塞形式。它表示正在抽取消息的線程的狀態。如果 UI 線程的大部分時間都處於此狀態，那就表示您的應用程序是有響應的。從另一方面來說，如果 UI 線程執行過多的工作，或由於其他原因而阻塞，那麼從應用程序用戶的角度來看，UI 就像掛起一樣。此類別提供了研究應用程序的響應能力和對其進行優化的好方法。
線程間依賴關系
“線程”視圖最有價值的功能之一是它能夠確定線程間的同步依賴關系。在圖 2 中，我已選擇了一個同步延遲段。該段已放大，且其顏色突出顯示（在此例中為紅色）。“當前堆棧”選項卡在此時顯示線程的調用堆棧。查看該調用堆棧，您便可以確定導致線程執行被阻塞的 API。
圖 2“線程”視圖
另一個可視化功能是將阻塞段連接到另一個線程的執行段的線條。當此可視化線條可見時，它將指明最終取消了被阻塞線程的阻塞狀況的線程。此外，在這種情況下，還可單擊“取消阻塞堆棧”選項卡以查看取消阻塞的線程在釋放被阻塞線程時在執行什麼操作。
舉例來說，如果阻塞線程在 Win32 關鍵部分中等待，則您將在其阻塞調用堆棧中看到 EnterCriticalSection 的簽名。當該線程取消阻塞時，應該會在取消阻塞的線程的調用堆棧中看到 LeaveCriticalSection 的簽名。分析復雜的應用程序行為時，此功能可能非常有價值。
報告
分析報告提供了一種簡單的方法來確定導致應用程序的性能行為的主要因素。無論您對執行開銷、阻塞開銷還是磁盤 I/O 感興趣，都可以通過這些報告著重關注可能值得研究的最重要的項目。
“線程”視圖中有四種報告：“執行采樣分析”、“阻塞分析”、“文件操作”和“每個線程的摘要”。所有這些報告都可使用圖例來訪問。例如，要查看“執行分析”報告，請單擊執行圖例項。此操作會在“分析報告”選項卡中生成報告。這些報告類似於圖 3 中顯示的內容。
圖 3 典型的分析報告
對於執行分析報告，Concurrency Visualizer 會分析對應用程序執行（綠色段）進行采樣時所收集的所有調用堆棧，並通過確定共享堆棧幀來對這些堆棧進行整理，從而幫助用戶了解應用程序的執行結構。該工具還會計算每個幀的包含成本和排除成本。包含樣本會計入給定執行路徑（包括其下的所有路徑）中的所有樣本。排除樣本則對應於調用圖堆棧幀的離開樣本的數量。
為獲取阻塞分析，請單擊圖例中您感興趣的阻塞類別。生成的報告結構類似於執行分析報告，但是包含列和排除列現在對應於歸於報告中調用堆棧或幀的阻塞時間。另一列顯示歸於調用樹中該堆棧幀的阻塞實例的數量。
在這些報告中，通過識別您的應用程序中造成大多數延時的部分，即可方便地排定性能優化工作的優先級。占用報告是信息性的，鑒於此類別的性質，這種報告通常不提供任何具備操作性的數據。您可在所有這些報告中跳轉至源代碼。可右鍵單擊您感興趣的堆棧幀來進行跳轉。您可利用顯示的上下文菜單跳轉到函數定義（使用 “查看源”選項），或跳轉到應用程序中調用函數的位置（使用“查看調用站點”選項）。如果有多個調用者，則將向您顯示多個選項。這樣就可將診斷數據和開發過程無縫集成，以調整應用程序的行為。還可以導出這些報告以做交叉分析比較。
圖 4 中顯示的“文件操作”報告包括當前時間范圍內的所有可見文件讀和寫操作的摘要。對於每個文件，Concurrency Visualizer 都會列出訪問它的應用程序線程、讀和寫操作的數量、讀或寫的總字節數以及讀或寫的總延遲時間。除了顯示直接歸因於應用程序的文件操作之外，Concurrency Visualizer 還會顯示系統進程執行的文件操作。如前所述，這些操作之所以顯示，是因為它們可能包括系統代表您的應用程序執行的文件操作。通過導出報告可以在執行優化工作時進行交叉分析比較。
圖 4 “文件操作”報告
圖 5 中顯示的“每線程摘要”報告為每個線程顯示了一個條形圖。條形圖中的條分為不同的線程狀態類別。要跟蹤性能優化進度，這可能是很有用的工具。導出不同優化迭代的圖形數據，就可記錄您的進度，並可比較運行。對於線程數過多而難以全部放入該視圖中的應用程序，該圖不會顯示其所有線程。
圖 5 每線程摘要報告
核心
上下文切換過多時，可能對應用程序性能造成不利影響，在線程在恢復執行時跨核心或處理器插口進行遷移的情況下尤其如此。這是因為一個正在運行的線程要將指令及其需要的數據（通常稱為工作集）加載到緩存層次結構中。當線程恢復執行時，尤其是在另一個核心上恢復執行時，它可能會在從內存或系統中的其他緩存重新加載其工作集時遇到長時間延遲。
有兩種常用方法可減少此類開銷。開發人員可解決底層原因來減少上下文切換的頻率，也可利用處理器或核心關聯。采用前一種方法通常更好，因為使用線程關聯可能會造成其他性能問題，因而只應在特殊情況下使用。“核心”視圖是可幫助確定線程關聯帶來的過多上下文切換或性能 Bug 的工具。
與其他視圖一樣，“核心”視圖在 X 軸上顯示時間線。系統中的邏輯核心顯示在 Y 軸上。將對應用程序中的每個線程分配一種顏色，且線程執行段將繪制在核心通道上。如圖 6 所示，將在底部窗格中顯示圖例和上下文切換統計數據。
圖 6“核心”視圖
這些統計數據可幫助用戶識別具有過多上下文切換的線程以及導致過多核心遷移的線程。然後，用戶可使用此視圖將注意力集中於待查線程執行被中斷的區域，或按照可見的顏色提示在核心之間來回跳轉。一旦確定了描述問題的區域，用戶就可將其放大並切換回“線程”視圖，以了解是什麼問題觸發了上下文切換，如有可能則解決這些問題（例如通過減少對關鍵部分的爭用）。有時，如果兩個或更多線程爭用一個核心，而其他核心空閒，則線程關聯 Bug 還可自行顯現。
支持 PPL、TPL 和 PLINQ
Concurrency Visualizer 不但支持現有 Windows 本機和托管編程模型，還支持 Visual Studio 2010 中提供的並行編程模型。一些新的並行構造（並行模式庫 (PPL) 中的 parallel_for、任務並行庫 (TPL) 中的 Parallel.For 以及 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 可視標記的示例
在 Concurrency Visualizer 中，TPL 和 PLINQ 不要求手動啟用同等功能的跟蹤。
收集分析
Concurrency Visualizer 支持用於收集分析的應用程序啟動和附加方法。具體行為與 Visual Studio 探查器的用戶所習慣的行為完全一樣。啟動圖 8 中顯示的“性能向導”，或使用“探查器”|“新建性能會話”選項，可通過“分析”菜單選項發起新的分析會話。在這兩種情況下，都可通過選擇“並發”分析方法，然後選擇“可視化多線程應用程序的行為”選項激活 Concurrency Visualizer。
圖 8 “性能向導分析方法”對話框
您可通過 Visual Studio 探查器的命令行工具收集 Concurrency Visualizer 跟蹤數據，然後使用 IDE 分析這些跟蹤數據。對無法安裝 IDE 的服務器場景感興趣的用戶，可通過這個命令行工具收集跟蹤數據，同時又將干擾降至最低。
您會注意到，Concurrency Visualizer 沒有集成對分析 ASP.NET 應用程序的支持。但是，在運行 ASP.NET 應用程序時，可以附加到主機進程（通常是 w3wp.exe）以分析其性能。
因為 Concurrency Visualizer 使用 Windows 事件跟蹤 (ETW)，所以需要管理權限才能收集數據。您可以作為管理員啟動 IDE，或者，系統會在需要時提醒您這樣做。在後一種情況下，IDE 將用管理員權限重新啟動。
將可視化項鏈接到應用程序階段
Concurrency Visualizer 中的另一項功能是可選的檢測庫，開發人員可使用該庫為他們所關心的應用程序階段繪制標記，從而自定義視圖。要在可視化項與應用程序行為之間更容易地建立關聯，這個庫有極高的價值。該檢測庫稱為 Scenario 庫，可從 code.msdn.microsoft.com/scenario 處的 MSDN 代碼庫站點下載。下面是使用 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);
}
對該庫的使用相當簡單，只需包含 Scenario 頭文件並鏈接正確的庫即可。然後，創建一個或多個 Scenario 對象，並調用 Begin 和 End 方法分別標記每個階段的開頭和結尾。還要為這些方法指定每個階段的名稱。可視化項與圖 7 中所示基本相同，不同之處在於工具提示將顯示您在代碼中指定的自定義階段名稱。此外，Scenario 標記在“CPU 使用率”視圖中也可見，但其他標記並不是這樣。還提供了一個同等的托管實現。
在此處應謹慎操作。應保守地使用 Scenario 標記；否則，可視化項可能會因這些標記而變得完全模糊不清。實際上，為了避免此問題，該工具在檢測到過多使用這種標記的情況時，將大大減少其數量或將其完全消除。在這種情況下，可放大以顯示已在大多數視圖中省略的標記。此外，如果有嵌套的 Scenario 標記，只會顯示最裡面的標記。
資源和勘誤表
Concurrency Visualizer 中有許多功能可幫助您了解其視圖和報告。這樣的功能中最有趣的是所有視圖的右上角顯示的“釋義”按鈕。單擊“釋義”，您就可以看到一個特殊的鼠標指針，您可用它來單擊視圖中您想獲得幫助的任何功能。我們借此在該工具中提供上下文相關幫助。
此外，還有一個“提示”選項卡中含有更多幫助內容，包括指向一些常見性能問題的可視化簽名庫的鏈接。
前面提到過，該工具可利用 ETW。Concurrency Analyzer 需要的一些事件在 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 中的另一個有價值的並發工具，該工具可通過選擇“收集資源爭用數據”選項來啟用。
在某些情況下，在分析場景中存在大量活動時，或其他應用程序在爭用 I/O 帶寬時，可能會丟失重要的跟蹤事件。這會導致跟蹤分析時發生錯誤。可以通過兩種方法來處理這種情況。首先，可嘗試減少活動應用程序的數量再分析一次，為了盡可能減少優化應用程序時的干擾，這是一個好方法。在這種情況下，命令行工具是另一種選擇。
第二，您可以增加 ETW 內存緩沖區的數量或大小。我們在輸出窗口中通過一個鏈接提供了文檔，該連接指向有關如何完成此操作的說明。如果選擇第二種方法，請設置收集到合理的跟蹤數據所需要的最小緩沖區總大小，因為使用這些緩沖區時，會消耗重要的內核資源。
任何診斷工具的好壞都取決於它向用戶返回的數據。Concurrency Visualizer 可幫助您通過參考源代碼查明性能問題的根本原因，但為了執行此操作，需要能夠訪問符號文件。可使用“工具”|“選項”|“調試”|“符號”對話框在 IDE 中添加符號服務器和路徑。將隱式包含您當前解決方案的符號，但是在研究可以在何處找到重要的符號文件時，應該啟用 Microsoft 公共符號服務器以及特定於應用程序的任何其他路徑。啟用符號緩存也是個好辦法，這樣做將大大減少分析時間，因為緩存中會填入您需要的符號文件。
雖然 ETW 提供了低開銷的跟蹤機制，但是 Concurrency Visualizer 收集的跟蹤數據仍可能很大。分析很大的跟蹤數據可能非常耗時，並且可能在實現該工具所提供的可視化功能時帶來性能開銷。通常，為了最大程度減少這些問題可能對您的體驗造成的影響，收集分析數據的持續時間不應超過一到兩分鐘。對於大多數分析場景，這樣長的持續時間已足以確定問題。為了避免在應用程序到達興趣點之前收集數據，附加到正在運行的進程也是一項重要的功能。
有多個有關 Concurrency Visualizer 的信息源。請訪問 Visual Studio 探查器論壇 (social.msdn.microsoft.com/forums/en-us/vstsprofiler/threads)，以獲取社區和開發團隊對相關問題的解答。在 blogs.msdn.com/visualizeparallel 處的團隊博客和 blogs.msdn.com/hshafi 處我的博客中，還提供了更多的信息。如對我們的工具有任何疑問，歡迎聯系我或我的團隊。我們樂於傾聽 Concurrency Visualizer 的用戶的意見，您的參與將幫助我們改進該工具。
