這里要指出的是， 運行一段程序，使用的cpu時間，跟實際運行的時間是不一樣的。附例如下：

程序輸出如下：
循環次數:1000 CPU時間(毫秒)=50.072 實際時間(毫秒)=666.9071
1 tick = 0.0001毫秒

可以看出在這個例子中，兩者差距比較大，其原因如下：

1）Windows是多任務操作系統，按照線程為單位對cpu時間輪詢分配。即一個程序運行的中途，可能被剝奪cpu資源，供其他程序運行。
2）程序本身會有不占用cpu時間的等待過程。這個等待可能是我們程序主動的，比如啟動一個進程，然后等待進程的結束；也可能是我們沒有意識到的，如例子 的Console.WriteLine方法，猜想其內部進行了一系列的異步I/O操作然后等待操作的完成，這其間并沒有占用調用進程的cpu時間，但耗費 了很多等待時間。
總結：
1）性能的測量，應該用程序運行時間來測量，當然也需要使用cpu時間作為參考，如果兩者差距很大，需要考慮為何出現這種情況。
2）.Net的Stopwatch類可以精確到1/10000毫秒，基本可以滿足測量精度。

個人整理：
Elapsed和ElapsedMilliseconds屬性在被調用時，會在內部調用kernel32中的QueryPerformanceFrequency()函數以獲取處理器支持的高精度計時器的頻率，隨后用這個數字對獲取的時間差值進行修正，最后Elapsed屬性會返回一個新的TimeSpan對象。而獲取ElapsedTicks屬性時則不會進行這種高精度的計算(修正)。但是一般來說這兩者的誤差并不是很大。如果需要精確計算時間或是測試數據量特別大的情況下，推薦使用Elapsed和ElapsedMilliseconds屬性。

存在疑問：
我測試之后發現并沒有像如下所說的結論，我已經回復原作者，暫未得到答復。希望知道原因的朋友指明下。謝謝。
從內部實現來看，StopWatch.IsHighresolution = true時，StopWatch.Elapsed.Ticks應該等于StopWatch.ElapsedTicks再乘以frequency（頻率的常量）。反之，這2個數在IsRunning為true時，應該是相等的。所以照理應該是StopWatch.Elapsed.Ticks會比較大。