何时通过代码优化“内联”属性

Question

这是一种noob问题。我有一个简单的属性

bool IsRoot { get { return parent==null; } } 

，我打电话过去，在类中的其他属性和方法很多次（和派生类）

我想保持它喜欢这样，因为它使代码可读性（对我来说），但恐怕所有的IsRoot调用都会​​让我放慢脚步，因为它们可能不会在最终版本代码中“内联”。我所说的“内联”是指用parent==null评估版本代替get_IsRoot()替换它们。

有人可以向我解释什么时候（或如果）属性在C＃中内联，而面向性能的应用程序是属性要避免或不？

EDIT_1： 简短的回答是：属性转换为纯函数调用，他们可能，或者根据什么决定JIT可能不会被内联。相信系统做出正确的选择，不要担心可能会影响5％-10％级别事情的事情，除非使用分析器，并且最终结果会根据性能进行调整。

感谢您的链接SO社区，我希望有一种方法来奖励多个正确的答案。对不起，我必须选择一个。

Answer 1

Here is an OLD post from Eric Gunnerson谈到有关内联。
要点是抖动决定是否内联函数。我的理解是，你可以通过编写小函数在某种程度上“鼓励”内联，但我不知道它的可靠程度如何。

Here is another link从一个问题在这里SO问一个类似的问题。包括许多良好的链接。

这里是从我张贴的第二链路的链接之一的摘录：

频繁使用可以在内衬到调用代码短而简单的方法。目前，JIT被记录（可能在此处更详细地描述）以内联长度小于32字节的方法，不包含任何复杂的分支逻辑，并且不包含任何与异常处理相关的机制。有关此主题的其他信息，请参阅David Notario的博客（请注意，它与CLR 2.0并不完全相关）。

我想这算作一个粗略的指南时的方法可能内联，但我不认为你可以说，如果一个方法不符合上述这将被内联的标准。

在一个侧面说明，您可以强制功能不能被内联升IKE在此：

[MethodImpl(MethodImplOptions.NoInlining)] 
public void DoNotInlineMe() 
{ 
    Console.WriteLine("Hello from non-inlined method"); 
} 

Answer 2

我认为这会回答你的问题

Does C# inline properties?