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

　　自從開始考慮代碼的運行效率和性能之後，寫代碼考慮的東西愈來愈多了，好比何時應該加try/catch？加太多的try/catch會不會下降性能？今天就來分享一下對try/catch對性能影響的一些見解。下面先來看三個問題：

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

問題一的回答:

　　一、 try{ }部分和不加try/catch語句塊的效率幾乎同樣, catch{}部分彷佛須要100倍以上的時間 ,因此只要不把try{}catch{}做爲你的程序的邏輯,這種設計就是合理的.

     二、從個人經驗看來，在 try 中的代碼和在沒有 try 的狀況下的效率是同樣的，沒有影響。

 

問題二: 若是有區別,那麼這樣的區別對性能的影響有多大呢?

問題二的回答:

　　一、當同一類型的異常被第一次拋出的時候，明顯能夠感到效率的下降；但其後再拋出就沒什麼感受了。仍是什麼文章中看到過這樣的說法：CLR的異常處理機制相比C++要高效不少。

　　二、就我學到的編譯知識，感受TRY CATCH會小小影響編譯的速度，由於翻譯模式內要回填異常的處理地址，而在運行期間應該不會影響速度

　　三、沒什麼大的影響，對如今的機器配置來講，這點影響微不足道

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

 

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

問題三的回答:

　　一、從硬件角度講，異常和中斷是一樣的機理，都是在知足必定的條件的時候，由軟件和硬件觸發，並經過向量轉到相應的處理程序。所以，異常在沒有被觸發的時候，應該是不會對性能形成影響的。
另外，.net在產生異常時是逐步向外層查找處理程序的，就是說，若是當前函數中沒有對異常進行處理，才查找調用當前函數的那一個函數，一直找遍整個應用程序，若是尚未，就交給runtime,在這種狀況下，效率纔是最低的，並且比較難於處理。

　　二、若是發生了異常,我認爲捕獲的越早效率越高,但每每咱們須要在一個合適的層面上來捕捉,因此有一個平衡問題,仍是得具體問題具體分析.  

　　三、我的以爲try catch語句是偵測語句。 

try
{ 
     須要偵測語句 
}
catch(跟蹤錯誤類)
{ 
      錯誤操做語句 
}

try偵測語句運行狀況:
     一、 當偵測語句運行出錯時,拋出錯誤類,而後根據錯誤類提供的信息,執行錯誤操做語句.   
     二、使用try catch語句效率低下我以爲有幾個緣由,首先因爲程序須要進行錯誤偵測,那麼執行偵測語句時須要更多的資源,其次,錯誤操做語句也要消耗相應的資源.  

 

個人總結:

      .net在產生異常時是逐步向外層查找處理程序的,所以能夠說捕獲的越早效率越高.若是當前應用程序沒有對異常進行處理，那麼當捕獲到異常時就會一層一層向外查找，若是沒有查找到異常處理程序，就交給runtime,在這種狀況下，效率纔是最低的，並且比較難於處理。

      對於性能上的開銷,按照以上的信息基本能夠忽略,由於"就算你不寫代碼去捕獲可能出現的異常，.net Framework在運行時也會幫你捕獲運行時出現的異常，轉向其異常處理程序...".因此只要你的catch是用來捕獲的不可預知的異常應該就不會有額外的開銷.

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

經驗告訴我彷佛即便程序不出現異常時彷佛加了try catch的仍是要稍慢,我的認爲不加try catch時代碼的運行速度應該比較快.

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

 

 

歡迎你們一塊兒探討!