做為一個有經驗的程序員，不管你在使用C#以前是習慣用什麼語言的，我們 綜合了幾個可以讓你開發出有效代碼的實際方法。有些時候，我們在先前的環境 中所做的努力在.Net環境中卻成了相反的。特別是在你試圖手動去優化一些代碼 時尤其突出。你的這些行為往往會阻止JIT編譯器進行最有效的優化。你的以性 能為由的額外工作，實際上產生了更慢的代碼。你最好還是以你最清楚的方法寫 代碼，其它的讓JIT編譯器來做。最常見的一個例子就是預先優化，你創建一個 很長很復雜的函數，本想用它來避免太多的函數調用，結果會導致很多問題。實 際操作時，提升這樣一個函數的邏輯到循環體中對.Net程序是有害的。這與你的 真實是相反的，讓我們來看一些細節。
這一節介紹一個簡單的內容，那 就是JIT編譯器是如何工作的 。.Net運行時調用JIT編譯器，用來把由C#編譯器 生成的IL指令編譯成機器代碼。這一任務在應用程序的運行期間是分步進行的。 JIT並不是在程序一開始就編譯整個應用程序，取而代之的是，CLR是一個函數接 一個函數的調用JIT編譯器。這可以讓啟動開銷最小化到合理的級別，然而不合 理的是應用程序保留了大量的代碼要在後期進行編譯。那些從來不被調用的函數 JIT是不會編譯它的。你可以通過讓JIT把代碼分解成更多的小塊，從而來最小化 大量無關的代碼，也就是說小而多的函數比大而少的函數要好。考慮這個人為的 例子：
public string BuildMsg( bool takeFirstPath )
{
StringBuilder msg = new StringBuilder( );
if ( takeFirstPath )
{
msg.Append( "A problem occurred." );
msg.Append( "\nThis is a problem." );
msg.Append( "imagine much more text" );
} else
{
msg.Append( "This path is not so bad." );
msg.Append( "\nIt is only a minor inconvenIEnce." );
msg.Append( "Add more detailed diagnostics here." );
}
return msg.ToString( );
}
在BuildMsg第一次調用時，兩個選擇 項就都編譯了。而實際上只有一個是須要的。但是假設你這樣寫代碼：
public string BuildMsg( bool takeFirstPath )
{
if ( takeFirstPath )
{
return FirstPath( );
} else
{
return SecondPath( );
}
}
