C# 编译器或 JIT 在什么级别优化应用程序代码？答案

【问题标题】：At what level C# compiler or JIT optimize the application code?C# 编译器或 JIT 在什么级别优化应用程序代码？
【发布时间】：2011-06-04 07:42:20
【问题描述】：

我想知道这些信息以减少我的代码大小，这样我就不会浪费我的时间来优化将由编译器或 JIT 完成的事情。

例如：

如果我们假设编译器将调用内联到属性的 get 函数，那么我不必将返回值保存在局部变量中以避免函数调用。

我想推荐一个很好的参考来描述正在发生的事情？

【问题讨论】：

【解决方案1】：

您可能想看看这些文章：

老实说，您不应该过多担心这种级别的微观细节。让编译器/JIT'er 为你担心这个，它比你在几乎所有情况下都做得更好。不要挂断Premature Optimisation。专注于让您的代码正常工作，然后在 (a) 它运行速度不够快，(b) 您有“大小”问题时担心以后的优化。

【讨论】：

【解决方案2】：

如果您担心性能，请运行分析器。然后更改代码。很有可能，在一百万年后，您永远不会 100% 正确地猜出时间的去向。您可能会更改 0.02% 的时间，并留下造成 62% 负担的方法。你也可能使情况变得更糟。没有分析器和证据，你就是瞎子。

您不能假设 JIT 将内联属性获取器。它可能会或可能不会这样做的原因有很多；方法体的大小、虚拟、值与引用类型、架构、附加的调试器等。

“吊装”还有一席之地，仍然可以实现节省如果代码在一个紧密的循环中被重复调用；例如：

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

（忘记上面的for 与foreach 的辩论——这是一个正交的讨论）。在上面，“提升”将有助于性能。但只是为了真的令人困惑 - 对于数组，情况正好相反，不提升它更有效：

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

JIT 识别出这一点并移除边界检查（因为数组是固定大小的）。

【讨论】：

感谢您提供信息，但我想为这些信息提供一个很好的参考
我的意思是，no 参考资料确实可以帮助您解决这个问题。 profiler 会。
plusitty plus plus。参考将帮助您在分析器向您显示需要时间之后。没有任何参考可以涵盖现实世界中存在的事物的广泛可能组合。请注意，许多分析器不允许（或必须被告知允许）内联函数，这样可能会扭曲您的分析信息。对于大多数人来说，我怀疑这是否重要。如果您认为内联是一件大事，那么您应该知道使用分析器...

【解决方案3】：

这看起来像是一种你不应该看的微优化。如果我没记错的话，这取决于应用了哪种优化的 CLR 的架构和版本。

如果你的方法被调用了这么多，而你真的希望它内联，你可以自己内联它，代价是意大利面条式的代码。

我建议分析您的算法，内联方法不会节省大量速度，而更好的算法可以使您的运行时间从几小时减少到几秒钟。

【讨论】：

【解决方案4】：

JIT 执行的最强大的优化通常是内联。 JIT 甚至可以内联数百个函数（我听说 JikesRVM 的这个数字）。他们甚至会内联并不总是可以内联的东西，并在以后需要时将其撤出（称为动态去优化）。

对于您的具体问题，我可能会说，如果有问题的函数调用是 hot。

【讨论】：