由C#或其它能產生受管代碼的編譯器所生成的受管代碼就是IL碼。雖然IL代碼被包裝在一個有效的PE文件中，但是你還是不能執行它，除非它被轉換成為受管原始代碼。這就是NGWS runtime 即時編譯器(也稱作JITters)大顯身手的時候。

為什么你會對即時編譯代碼感到厭繁， 為什么不把整個IL PE文件編譯成原始代碼? 答案是時間——需要把IL代碼編譯成CPU規ge的代碼的時間。這種編譯將更加有效率，因為一些程序段從來就沒有被執行過。例如，在我的字處理器中，郵件合并功能從來就沒有被編譯。

從技術上說，全部的處理過程如下：當一個類型被裝載時，裝載器創建一個存根(stub)，并使它連接每一個類型的方法。當一個方法第一次被調用時，存根把控制交給JIT。JIT把IL編譯為原始代碼，且把存根指針指向裝入緩沖區的原始代碼。接著的調用將要執行的原始碼。在某些位置上，所有的IL都被轉換成為原始代碼，這時JITter處于空閑狀態。

正如我在前面提到的，JIT編譯器有很多，不止一個。在Windows平臺上，NGWS runtime帶有3個不同的JIT編譯器。

JIT——這是NGWS runtime默認使用的JIT編譯器。它是一個后臺優化的編譯器 ，在前臺實行數據流分析，并創建了高度優化的受管原始代碼作為輸出結果。JIT可以使用不嚴ge的IL指令集編碼，但是所需資源將十分可觀。主要的限制在于內存足跡(footprint)、結果工作集，以及實行優化所消耗的時間。

EconoJIT—— 和主JIT相比，EconJIT的目標是把IL高速地轉換成受管原始代碼。它允許把產生的原始代碼裝入緩沖區，但是輸出碼并不象主JIT生成的代碼那樣優化(代碼小)。當內存緊張時，快速代碼生成方案的優勢將蕩然無存。永久地丟棄無用的、已JIT過的代碼，就可以把更大的IL程序裝入代碼緩沖區。因為JIT編譯快，執行速度也仍然很快。

PreJIT——盡管它依據主JIT，但操作起來更象是一個傳統的編譯器。你安裝了NGWS組件，它才能運行，才可以把IL代碼編譯成受管原始代碼。當然最終的結果為，更快的裝載時間和更快的應用程序啟動時間(不需要更多的JIT編譯)。

在所列出的JITters中，有兩個是運行時的JITters?？墒悄阍趺礇Q定要使用哪一個JIT，它如何使用內存? 有一個稱為“JIT編譯管理器”的小應用程序(jitman.exe)，它存放在NGWS SDK安裝目錄下的bin目錄中。當執行該程序時，它把一個圖標加到系統任務條上，雙擊該圖標打開程序對話框

盡管它是一個小小的對話框，可是你所選擇的選項功能是相當強大的。每一個選項將在以下描述。

Use EconoJIT only 選項——當該復選框沒有選上時，NGWS runtime使用默認的正常的JIT編譯器。前面就曾經解釋過兩種JITter的區別。

Max Code Pitch Overhead(%)選項——該設置僅保留給EconoJIT。它控制了JIT編譯時間和執行代碼時間的百分比。如果超過了設定的值，代碼緩沖區得到擴充，以縮短JIT編譯所消耗的時間。

Limit Size of Code Cache選項——該項默認為沒有選中。沒有選擇該項意味著緩沖區將利用它所能得到的內存。如果你想限制緩沖區大小，選中該選項，這將允許你使用Max Size of Cache(bytes)選項。

Max Size of Cache(bytes)選項—控制容納JIT代碼的緩沖區的最大值。雖然你可以非常嚴ge地限制這個值，但你還是應該小心，不能超過這個緩沖區所適合的最大值。否則該方法的JIT編譯將會失敗。

Optimize For Size選項——告訴JIT 編譯器，優化的目的是為了使代碼更小而不是能執行得更快。這個設置默認是關掉的。

Enable Concurrent GC[garbage collection]選項——垃圾收集(GC)默認地運行在用戶代碼的線程中。意味GC發生時，可能會注意到回應有輕微的延遲。為防止出現該現象，打開當前GC。注意，當前GC比標準GC更慢，它僅在windows 2000上寫時(the time of writing)有效。

當用C#創建項目時，你可能使用不同的設置試驗過。當創建 UI-intensive應用程序時，你將會看到允許當前GC的最大差別。