C# 關於Try/Catch對系統效能影響的總結

標籤：style   blog   color   使用   strong   io   re   問題   

　　自從開始考慮代碼的運行效率和效能以後，寫代碼考慮的東西越來越多了，比如什麼時候應該加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{      需要偵測語句 }catch(跟蹤錯誤類){       錯誤動作陳述式 }

try偵測語句運行情況:
     1、 當偵測語句運行出錯時,拋出錯誤類,然後根據錯誤類提供的資訊,執行錯誤動作陳述式.   
     2、使用try catch語句效率低下我覺得有幾個原因,首先由於程式需要進行錯誤偵測,那麼執行偵測語句時需要更多的資源,其次,錯誤動作陳述式也要消耗相應的資源.  

 

我的總結:

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

      對於效能上的開銷,按照以上的資訊基本可以忽略,因為"就算你不寫代碼去捕獲可能出現的異常，.netFramework在運行時也會幫你捕獲運行時出現的異常，轉向其例外處理常式...".所以只要你的catch是用來捕獲的不可預知的異常應該就不會有額外的開銷.

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

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

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

 

 

歡迎大家一起探討!