C# 編譯器或 JIT 在什么級別優化應用程序代碼？

Question

我想知道這些信息以減少我的代碼大小，這樣我就不會浪費我的時間來優化將由編譯器或 JIT 完成的事情。

例如：

如果我們假設編譯器內聯對 get function 屬性的調用，那么我不必將返回值保存在局部變量中以避免 function 調用。

我想推薦一個很好的參考來描述發生了什么？

Answer 1

你可能想看看這些文章：

老實說，您不應該過多擔心這種級別的微觀細節。 讓編譯器/JIT'er 為您擔心這個問題，在幾乎所有情況下它都比您做得更好。 不要掛斷過早的優化。 專注於讓您的代碼正常工作，然后在 (a) 它運行速度不夠快，(b) 您有“大小”問題時擔心以后的優化。

Answer 2

如果您擔心性能，請運行分析器。 然后改代碼。 很有可能，在一百萬年后，您永遠不會 100% 正確地猜出時間的去向。 您可能會更改 0.02% 的時間，並留下造成 62% 負擔的方法。 你也可能使情況變得更糟。 沒有分析器和證據，你就是盲人。

您不能假設JIT 將內聯屬性獲取器。 它可能會或可能不會這樣做的原因有很多； 方法體的大小、虛擬、值與引用類型、架構、附加的調試器等。

“吊裝”還是有一席之地的，如果代碼在一個緊密的循環中重復調用，仍然可以實現節省； 例如：

var count = list.Count;
for(int i = 0 ; i < count ; i++) {...}

（忘記上面的for vs foreach辯論 - 這是一個正交討論）。 在上面，“提升”將有助於性能。 但只是為了真正令人困惑 - 對於 arrays，情況正好相反，不提升它更有效：

for(int i = 0 ; i < arr.Length ; i++) {...}

JIT 認識到這一點並刪除了邊界檢查（因為 arrays 是固定大小的）。

Answer 3

這看起來像是一種你不應該關注的微優化。 如果我沒記錯的話，這取決於應用哪種優化的 CLR 的體系結構和版本。

如果你的方法被調用了這么多，並且你真的希望它內聯，你可以自己內聯它，代價是意大利面條式的代碼。

我建議分析您的算法，內聯方法不會節省速度，而更好的算法可以使您的運行時間從幾小時減少到幾秒鍾。

Answer 4

JIT 執行的最強大的優化通常是內聯。 JIT 甚至可以內聯數百個函數（我聽說 JikesRVM 的這個數字）。 他們甚至會內聯並不總是可以內聯的東西，並在需要時將其退出（稱為動態去優化）。

對於您的具體問題，我可能會說，如果有問題的 function 調用很熱。