當自己程序遇到性能問題，比如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 的代碼覆蓋報告。
更多dottrace介紹，請猛擊這里。