當自己程式遇到性能問題，比如IIs請求反應緩慢，用戶端程式執行緩慢，怎麼分析是哪裡出了問題呢？dottrace可以幫助.net程式跟蹤出代碼裡每個方法的執行時間，這樣讓我們更清晰的看出是哪裡執行時間過長，然後再分析應該怎樣解決。
Dottrace是由JetBrainshttp://www.jetbrains.com/ 公司開發的一款産品，它分dottrace Performance和dottrace Memory 兩個工具，dottrace Performance用來分析代碼性能，比如函數執行時間，調用次數，消耗時間比率等，dottrace Memory一般用來分析記憶體占用情況。dottrace可以跟蹤.net編寫的：應用程式，IIS挂接的程式，windows服務，silverlight，WCF服務程式等。還可以把跟蹤的檔案，以快照的方式儲存下來，儲存為dtp字尾的檔案。跟蹤後的結果，如果能找到對應使用者的代碼資訊，還可以直接檢視對應的源代碼，并選擇在VS裡直接編輯該方法對應的檔案。
以下是一個跟蹤用戶端程式的示例：
1.選擇要追蹤的程式類型：
因為是用戶端程式，這裡我們選擇Standalone Application。
2.選擇可執行程式路徑和參數并配置追蹤方式：
如上圖，Application、Arguments分别對應可執行程式的路徑和需要的參數。
profiling type 有三種類型：
Tracing：它是通過擷取CLR内部一個方法開始執行和結束執行的時間差來計算的分析時間。
Line-by-line：它是通過收集代碼執行的每條語句的時間來，它計算出的時間更精确。
Sampling：它是抽樣的方式，每隔一段時間（windows下大概是10ms），會暫停所有線程，并抓取堆棧裡的資訊，然後計算出代碼執行時間差，這個選項可能會導緻一些執行很短的方法抓取不到的問題。
Measure的三種類型：
Wall time(performance counter)： 它是通過Performance Counter API來收集的資訊，一般作業系統和各個硬體裝置都提供性能計數的API供程式調用。
Thread time：它隻支援Sampling的分析方式，它通過一個固定的線程來抓取堆棧資訊計算時間，并且它隻計算自己内部程式執行的時間，不管等待其他IO的時間。
Wall time(CPU instruction)：它是通過讀取TSC processor register裡記錄的方法進入和退出時間差的方式來計算的。
根據上面的選項方式，一般我們要想完整分析自己程式的執行時間，建議可以采用Line-byline(或Tracing)和Wall time(CPU instruction)或Wall time(performance counter)的方式，因為如果用抽樣和Thread time的搭配方式，會隻計算自己内部時間，不能計算自己程式和外部程式互動的時間，會讓自己分析性能時産生誤導。
3.點選Run後會運作追蹤程式
然後點選上圖中的Get Snapshot就會産生程式執行的調用堆棧快照，裡面就有我們最關心的執行時間。
4.下圖是生成的結果：
上圖中左側紅框中對應結果的五個視圖：
Overview：這個可以看到該性能分析檔案的抓取方式，比如上面例子為Line-by-line,Wall Time(CPU instruction)的方式，抓取的URL位址等，還會有該視圖下的系統配置情況以及目前的子產品以及方法個數等資訊。
Threads Tree:記錄目前每個線程執行的方法，以及方法的性能情況。
Call Tree：不管線程，按所有請求的入口為一條資料展現，但裡面展現的排序是按照執行時間高低排序的，不是按照代碼順序展現的。
Plain List：展現所有非核心代碼的方法清單，并展現每個方法執行時間和被調用次數。
Hot Spots：它會把所有代碼包括核心代碼的方法，按照執行時間排序順序展現到清單，并記錄每個方法的執行時間比率和時間等資訊。
上圖中展示的就是Threads Tree視圖，從這個視圖中我們可以看到主線程以及多個托管線程的執行時間和每個方法執行的時間，這樣我們就很容易定位到程式的瓶頸所在。dottrace更多的應該是應用在iis網站性能分析上，它還能進行代碼調試，能夠分析 .NET 架構和 Silverlight 應用程式的語句級代碼覆寫。同時內建了 ReSharper 的單元測試工具集，突出顯示單元測試未覆寫的代碼，可以檢測出覆寫任何特别代碼位置的單元測試，生成基于 XML 的代碼覆寫報告。
本文轉自左正部落格園部落格，原文連結：http://www.cnblogs.com/soundcode/p/4447913.html，如需轉載請自行聯系原作者