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

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

例如：

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

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

您可能想看看这些文章：

JIT优化 – （Sasha Goldshtein – CodeProject）
Jit优化：内联我（David Notario）
Jit优化：内联II（David Notario）

说实话，你不应该过分担心这种微观细节。让编译器/ JIT’er为你担心这个问题，它比你在几乎所有情况下都要好。不要挂断过早优化。专注于让你的代码工作，然后担心如果（a）它运行得不够快，（b）你有“大小”问题，那么以后会进行优化。

如果您担心性能，请运行探查器。然后改变代码。有可能你将永远不会百万年在正确的时间里正确地猜测。你可以改变0.02％的时间，并留下造成62％负担的方法。你也可能让它变得更糟。没有剖析器和证据，你就是盲目的。

您不能假设 JIT将内联属性getter。它可能会或可能不会有很多原因; 方法体的大小，虚拟，值与引用类型，体系结构，附加的调试器等。

“吊装”仍然占有一席之地，如果在紧密循环中反复调用代码，仍然可以节省成本。例如：

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

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

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

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

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

如果你的方法调用那么多，并且你真的希望它内联，你可以自己内联它，代价是意大利面条代码。

我建议分析你的算法，内联方法不会保存速度，而更好的算法可以使你的运行时间从几小时减少到几秒。

JIT执行的最强大的优化通常是内联。 JIT甚至可以内联数百个函数（我听说过JikesRVM的这个数字）。他们甚至会内联那些并不总是可以内联的内容，如果需要，可以在以后再进行内联（称为动态去优化）。

一个很好的概述是http://java.sun.com/products/hotspot/docs/whitepaper/Java_Hotspot_v1.4.1/Java_HSpot_WP_v1.4.1_1002_4.html 。

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