在NET平台裡大部分編譯器的優化並不是通過VB和C#編譯器來完成的它們寧可把優化的處理推後到CLR的即時（Just In TimeJIT）編譯器讀取IL並轉換為原生機器碼的時候來完成由於這個原因對JIT的改變會極大地影響之前編譯好的程序集
一個主要的影響就是內聯函數（Inlining Function）調用之前JIT對內聯方法的處理非常保守Vance Morrison解釋了個中緣由
它對內聯的處理並不是很好內聯總是減少指令執行的數量（這是由於最低限度的調用和返回指令沒有被執行）但是它能（並經常）讓結果代碼變得很大大部分人都能直覺地理解內聯大的方法（比如Kb的）不是很有意義而內聯非常小的方法可以讓調用的占用空間更小（由於調用指令才字節）這樣的選擇總是正確的但是介於兩者之間的方法要如何處理呢？
有趣的是當你讓代碼變大時你也就讓它執行緩慢因為內存天生地緩慢你的代碼越大它越不會放在最快的CPU緩存（稱之為L）裡面執行在那樣的情況下處理器需要執行個周期直到它能從另外的緩存（稱之為L）中獲取到執行代碼如果L緩存中還不存在那麼就需要到主內存中獲取（需要花費+周期）對於在緊密循環中執行的代碼這樣的結果不會有什麼問題因為所有的代碼都適合放入到最快緩存中（典型的是K）不過對於常規的代碼它通過大量的方法來執行大量的代碼越大就越慢的效果就非常顯著更大的代碼也就意味著在啟動時從磁盤獲取代碼需要更大的磁盤I/O這就意味著你的應用程序啟動較慢
在Service Pack 中微軟引入了一個新的基於代碼尺寸的啟發式算法來判斷調用是否處於一個循環中在常規情況下函數只有當在調用空間中的結果機器碼比原始版本要小時才能被內聯這樣做就保證了盡可能多的代碼能適合CPU的緩存當緩存不夠用時就能對性能產生巨大的影響
當處在循環中時分部異常也可以很好地工作這是因為據推測函數通常會被多次調用所以CLR允許內聯函數可以增長至原始調用大小的倍大類似值類型優化這樣的條件有可能更進一步地增加容許尺寸的大小
From:http://tw.wingwit.com/Article/program/net/201311/14782.html
