属性/方法内联和对反射的影响答案

【问题标题】：Property / Method inlining and impact on Reflection属性/方法内联和对反射的影响
【发布时间】：2011-07-14 10:34:07
【问题描述】：

Valentin Kuzub 对我的answer 对 SO 的一个问题发表了评论，他认为 JIT 编译器内联属性将导致反射停止工作。

案例如下：

class Foo
{
    public string Bar { get; set; }

    public void Fuzz<T>(Expression<Func<T>> lambda)
    {
    }
}

Fuzz(x => x.Bar);

Fuzz 函数接受 lambda 表达式并使用反射来查找属性。这是 MVC 在 HtmlHelper 扩展中的常见做法。

我认为即使Bar 属性被内联，反射也不会停止工作，因为它是对Bar 的调用，它将被内联，typeof(Foo).GetProperty("Bar") 仍将返回一个有效的PropertyInfo。

您能否确认一下，或者我对方法内联的理解是错误的？

【问题讨论】：

顺便说一句，我发现这篇有趣的文章显示了在 INotifyPropertyChange 实现中不使用 lambda 的其他原因blog.quantumbitdesigns.com/2010/01/26/…

【解决方案1】：

JIT 编译器在运行时运行，它不能重写存储在程序集中的元数据信息。反射读取程序集以访问此元数据。所以 JIT 编译器对反射没有影响。

编辑：实际上，有几个地方 C# 编译器本身在编译期间“内联”了一些信息。例如，常量、枚举和默认参数是“内联的”，因此您无法在反射期间访问它们。但这绝对与您的具体情况无关。

【讨论】：

【解决方案2】：

是的，当我想得更多时，我猜只有内联属性可能会失败的方法 INotifyPropertyChanged 接口正确的工作是如果您使用的是基于反射的方法，例如

public Count
{
get {return m_Count;}
 set { m_Count=value;
      GetCurrentPropertyNameUsingReflectionAndNotifyItChanged();}
}

如果像您这样使用，则表明程序集中确实存在元数据，并且将从那里成功获取属性名称。

让我们俩都在思考。

【讨论】：

【解决方案3】：

我个人同意@Sergey：

考虑到内联发生在 JIT 编译器端，但之前生成的元数据，它不应该以任何方式影响反射。顺便问下，好问题，点赞+1

【讨论】：

【解决方案4】：

表达式树无论如何都不能内联，因为它们是表达式（抽象语法树）的表示，而不是表达式本身。

委托，即使它们可以内联，仍将在其属性中携带有关被调用的方法和目标的数据。

【讨论】：