C# 關于Try/Catch對系統性能影響的總結

　　自從開始考慮代碼的運作效率和性能以後，寫代碼考慮的東西越來越多了，比如什麼時候應該加try/catch？加太多的try/catch會不會降低性能？今天就來分享一下對try/catch對性能影響的一些看法。下面先來看三個問題：

問題一:當一段代碼被try塊包圍後與不加try時在沒有異常發生的情況下,執行過程是否有差別?

問題一的回答:

　　1、 try{ }部分和不加try/catch語句塊的效率幾乎一樣, catch{}部分似乎需要100倍以上的時間 ,是以隻要不把try{}catch{}作為你的程式的邏輯,這種設計就是合理的.

     2、從我的經驗看來，在 try 中的代碼和在沒有 try 的情況下的效率是一樣的，沒有影響。

問題二: 如果有差別,那麼這樣的差別對性能的影響有多大呢?

問題二的回答:

　　1、當同一類型的異常被第一次抛出的時候，明顯可以感到效率的降低；但其後再抛出就沒什麼感覺了。還是什麼文章中看到過這樣的說法：CLR的異常處理機制相比C++要高效很多。

　　2、就我學到的編譯知識，感覺TRY CATCH會小小影響編譯的速度，因為翻譯模式内要回填異常的處理位址，而在運作期間應該不會影響速度

　　3、沒什麼大的影響，對現在的機器配置來說，這點影響微不足道

　　4、對效率的影響不大，可以放心使用。因為就算你不寫代碼去捕獲可能出現的異常，.net Framework在運作時也會幫你捕獲運作時出現的異常，轉向其異常處理程式，結果就是彈出對話框來提示你，我想大家在調試的時候都見識過吧。  

問題三: try的代碼究竟做了些什麼?他對代碼做的是每次執行時監視還是以類似中斷的的方式,當出現異常時主動調用什麼過程轉向異常處理.?

問題三的回答:

　　1、從硬體角度講，異常和中斷是同樣的機理，都是在滿足一定的條件的時候，由軟體和硬體觸發，并通過向量轉到相應的處理程式。是以，異常在沒有被觸發的時候，應該是不會對性能造成影響的。

另外，.net在産生異常時是逐漸向外層查找處理程式的，就是說，如果目前函數中沒有對異常進行處理，才查找調用目前函數的那一個函數，一直找遍整個應用程式，如果還沒有，就交給runtime,在這種情況下，效率才是最低的，而且比較難于處理。

　　2、如果發生了異常,我認為捕獲的越早效率越高,但往往我們需要在一個合适的層面上來捕捉,是以有一個平衡問題,還是得具體問題具體分析.  

　　3、個人覺得try catch語句是偵測語句。 

try偵測語句運作情況:

     1、 當偵測語句運作出錯時,抛出錯誤類,然後根據錯誤類提供的資訊,執行錯誤操作語句.   

     2、使用try catch語句效率低下我覺得有幾個原因,首先由于程式需要進行錯誤偵測,那麼執行偵測語句時需要更多的資源,其次,錯誤操作語句也要消耗相應的資源.  

我的總結:

      .net在産生異常時是逐漸向外層查找處理程式的,是以可以說捕獲的越早效率越高.如果目前應用程式沒有對異常進行處理，那麼當捕獲到異常時就會一層一層向外查找，如果沒有查找到異常處理程式，就交給runtime,在這種情況下，效率才是最低的，而且比較難于處理。

      對于性能上的開銷,按照以上的資訊基本可以忽略,因為"就算你不寫代碼去捕獲可能出現的異常，.net

Framework在運作時也會幫你捕獲運作時出現的異常，轉向其異常處理程式...".是以隻要你的catch是用來捕獲的不可預知的異常應該就不會有額外的開銷.

新的疑問:異常交給runtime進行處理效率才是最低的?

經驗告訴我似乎即使程式不出現異常時似乎加了try catch的還是要稍慢,個人認為不加try catch時代碼的運作速度應該比較快.

猜測:我想編譯時在哪個層次上有異常處理應該是被标記了的.該層以下一旦有catch類型異常就跳轉到catch塊.進而也影響了最終編譯程式的大小.

歡迎大家一起探讨!