Effective C# 儘可能實現短小簡潔的函數

對於有經驗的程式員來說，不論在接觸C#之前使用什麼語言，都有一些提高代碼效率的方法。不過有些做法雖然在之前的語言中有效，但在.Net環境中卻適得其反。

      這一點在我們嘗試手動為C#編譯器最佳化演算法時尤為明顯。我們的舉動往往使得JIT編譯無法做出更加有效最佳化。那些以最佳化為目的的工作，結果往往是產生更慢的代碼。我們完全不必追求建立最直截了當的代碼，有些工作完全可以交給編譯器完成。有些過分最佳化會造成問題，一個典型的例子就是我們為了避免進行函數調用而建立一個又長又複雜的函數。這樣的做法會降低.Net應用程式的表現，是和初衷相違背的。讓我們來注意一下其中的細節。

      這裡簡單的介紹一下JIT編譯的工作原理。.Net在運行時通過JIT編譯器將C#編譯器產生的IL轉換為機器代碼。這個工作貫穿在程式啟動並執行生命週期中。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被調用，所有的代碼都會被JIT編譯。但其中只有一條路徑上的代碼是有用的。但是我們可以考慮這樣改進函數：

 

public
string BuildMsg(bool takeFirstPath)
        
{
            StringBuilder msg =
new StringBuilder();
            if (takeFirstPath)
            
{
                return FirstPath();
            }
            else
            
{
                return SecondPath();
            }
        }

 

   不同於最開始的代碼，現在每個分支都調用了它們各自的函數。這種做法節省了運行時的消耗，雖然這點看起來消耗微不足道。但是我們考慮一下更極端一點的例子：一個if的兩個分支中各包含有20個甚至更多分支。原先的做法會在開始時將整個函數讀入，招致不必要的消耗。如果將函數細化JIT編譯器就會以需求邏輯對函數進行編譯。那些不必需的代碼就不會馬上被編譯。對於那些較長的switch分支來說，將每個case分別定義為不同的函數可以將消耗節省幾倍。

      小而簡單的函數有助於JIT編譯器更輕鬆的對其進行註冊。通過註冊，局部變數可以被儲存在寄存器中而不是棧中。建立較少的局部變數有助於JIT編譯器找到最佳候選註冊變數。同樣控制流程程也會影響到JIT編譯器註冊變數。如果一個函數中包含一個迴圈，那麼這個迴圈變數就很可能被註冊。但是一旦一個函數中有多個迴圈，那麼JIT編譯器就必需在這些迴圈變數中做出一些選擇。簡單的函數可能包含較少的局部變數，這有助於JIT編譯器最佳化對寄存器的使用。