眾所周知.NET在第一次執行的時比第二第三次的效率要低很多，最常見的就是ASP.NET中請求第一個頁面的時候要等上一段時間，而後面任意重新整理響應都非常迅速，那麼是什麼原因導致的呢？為什麼微軟不解決這個問題呢？
問題
首先大家可以在心底回答這幾個問題，這也是讀完本文之後會陸續解決的問題。
1.生成就是編譯嗎？
2.既然執行過一次之後效率會高很多為什麼微軟不解決這樣的問題呢？
3.預編譯比JITCompiler的方式好嗎？
效率比較
第一次執行耗費了399
第二次執行耗費了5
為什麼差這麼多呢？後面就讓我們來揭曉。
注：單位不是ms（毫秒）
生成就是編譯嗎？
首先我先回答第一個問題：生成也是編譯（語言編譯），只不過不是編譯成機器碼（彙編），而是“IL”，但一般人會聽到編譯都聯想到編譯成機器碼（彙編），所以大家最好叫生成。
既然在生成的時候沒有編譯成機器碼，那麼計算機是如何執行的呢？下面我們來看描述了方法首次呼叫的一幅圖，摘自網路。
可以看出，在WriteLine下有個JITCompiler，沒錯就是這個函式幫我們把WriteLine編譯成了機器碼。
那當第二次執行的時候JITCompiler會變成原生程式碼，也就是說JITCompiler不會再次執行了，順帶得到的好處就是效率提升了。
既然執行過一次之後效率會高很多為什麼微軟不解決這樣的問題呢？
為什麼微軟不再VS生成的時候就編譯成機器碼呢？
其實微軟有提供相關的設定（預編譯），但不推薦使用。
微軟既然提供了預編譯為什麼不把它設為預設的呢？
這個就得跳到第三個問題咯，大家繼續往下看。
預編譯比預設的方式好嗎？
多平臺支援
再寫完一個程式時（WinForm比較常見）可以發現可疑同時執行在x86和x64的平臺上，那為什麼x64的作業系統一開始會有那麼多的x86軟體相容問題呢？
其實針對x86和x64平臺的指令是有區別的，深入的我也不太瞭解，有大牛可以細說說。
那為什麼一次生成可以同時在x64和x86上同時執行呢？
原因其實很簡單：JITCompiler是在執行方法時才會將IL編譯成機器碼，那麼微軟當然有辦法根據平臺的差異性編譯出對應的機器碼。
忽略不適應程式碼
1: if (numberOfCPUs > 1) {
2: ...
3: }
如果主機只有一個CPU,JIT編譯器不會為上述程式碼生成任何CPU指令,那麼這樣順帶的結果就是最終的程式碼變得更小,執行的更快（可能有人說扯淡，就算一個CPU的這段程式碼也不會執行啊，那麼大家得考慮機器碼不是物件導向的語言可能一個小小的if就會順帶很多指令）。
未來還有更多
這種優化未來只會更多，因為CLR在不停的更新。。。
拋棄預編譯嗎？
答案肯定是否的，預編譯有自己的優勢，如果你所寫的程式碼只在一臺伺服器或者少個數的伺服器上執行，那麼完全可以針對伺服器進行預編譯，但面向多服務端、客戶端的程式還是最好採用JIT編譯。
結語
部分引自：CLR via C#（第三版）
其實我覺得.NET並不是完全的編譯型語言，從JIT編譯來看他也是一種解析執行語言（把IL解析成機器語言）。