C# Property Access Optimization

In C# (or VB .NET), does the compiler make attempts to optimize property accesses? For eg.,

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

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

I would imagine that if the compiler could somehow detect that View remains constant between the two accesses, it can refrain from computing the value twice. Are these kind of optimizations performed?

I understand that if View has some intensive computations, it should probably be refactored into a function (GetView()). In my particular case, View involves climbing the visual tree开发者_开发百科 looking for an element of a particular type.

Related: Any references on the workings of the (Microsoft) C# compiler?

---

Not in general, no. As Steven mentioned there are numerous factors to consider regarding multithreading, if you truly are computing something that might change, you're correct it should be refactored away from a property. If it won't change, you should lazy-load it (check if the private member is null, if so then calculate, then return the value).

If it won't change and depends on a parameter, you can use a Dictionary or Hashtable as a cache - given the parameter (key) you will store the value. You could have each entry as a WeakReference to the value too, so when the value isn't referenced anywhere and garbage collection happens, the memory will be freed.

Hope that helps.

---

The question is very unclear, it isn't obvious to me how the getter and the snippet below it are related. But yes, property accessors are normally heavily optimized. Not by the C# compiler, by the JIT compiler. For one, they are often inlined so you don't pay for the cost of a method call.

That will only happen if the getter doesn't contain too much code and doesn't monkey with locks and exception handling. You can help the JIT compiler to optimize the common case with code like this:

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

This will inline the common case and allow the creation method to remain un-inlined. This gets typically compiled to three machine code instructions in the Release build (load + test + jump), about a nano-second of execution time. It is a micro-optimization, seeing an actual perf improvement would be quite rare.

Do note that the given sample code is not thread-safe. Always write correct code rather than fast code first.

---

No, which is why you should use Lazy<T> to implement a JIT calculation.

---

From my understanding there is no implicit caching - you have to cache the value of a given property yourself the first time it is calculated

For example:

  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;
        }