C＃属性访问优化

Question

在C＃（或VB .NET）中，编译器是否尝试优化属性访问？ 例如，

public ViewClass View
{
    get
    {
        ...
        Something is computed here
        ....
    }
}

if (View != null)
    View.Something = SomethingElse;

我想如果编译器能够以某种方式检测到View在两次访问之间保持不变，它可以避免两次计算该值。 是否进行了这些优化？

我知道如果View有一些密集的计算，它可能应该重构为一个函数（ GetView() ）。 在我的特定情况下， View涉及攀爬可视树以查找特定类型的元素。

相关：关于（Microsoft）C＃编译器的工作原理的任何参考？

Answer 1

不一般，没有。 正如史蒂文所提到的，关于多线程有许多因素需要考虑，如果你真的在计算可能会改变的东西，那么你是正确的，它应该被重构而不是属性。 如果它不会改变，你应该延迟加载它（检查私有成员是否为null，如果是，则计算，然后返回值）。

如果它不会改变并依赖于参数，则可以使用Dictionary或Hashtable作为缓存 - 给定参数（key），您将存储该值。 您可以将每个条目作为值的WeakReference ，因此当值未在任何地方引用并且垃圾收集发生时，将释放内存。

希望有所帮助。

Answer 2

这个问题非常不清楚，对我而言，下面的吸气剂和片段是如何相关的并不明显。 但是，属性访问器通常会进行大量优化。 不是由C＃编译器，而是由JIT编译器。 例如，它们经常被内联，因此您无需支付方法调用的费用。

只有当getter不包含太多代码并且没有使用锁和异常处理时才会发生这种情况。 您可以帮助JIT编译器使用以下代码优化常见情况：

get
{
    if (_something == null) {
        _something = createSomething();
    }
    return _something;
}

这将内联常见情况并允许创建方法保持非内联。 这通常在Release版本（加载+测试+跳转）中编译为三个机器代码指令，大约执行时间为纳秒。 这是一个微观优化，看到实际的性能提升将是非常罕见的。

请注意，给定的示例代码不是线程安全的。 始终首先编写正确的代码而不是快速代码。

Answer 3

不，这就是你应该使用Lazy<T>来实现JIT计算的原因。

Answer 4

根据我的理解，没有隐式缓存 - 您必须在第一次计算时自己缓存给定属性的值

例如：

  object mCachedValue = null;
    public Object MyProperty
    {
        get
        {

            if (mCachedValue == null)
            {
               lock(mCachedValue)
                {
                   //after acquiring the lock check if the property has not been initialized in the mean time - only calculate once
                    if (mCachedValue == null)
                    {
                        //calculate value the first time 
                    }
                }
            }
            return mCachedValue;
        }