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

Не в общем, нет. Как отметил Стивен, есть множество факторов, которые следует учитывать в отношении многопоточности, если вы действительно используете что-то, что может измениться, вы правы, его нужно переучивать вне собственности. Если это не изменится, вы должны lazy-load it (проверьте, является ли частный член нулевым, если он затем вычисляет, а затем возвращает значение).

Если он не изменится и зависит от параметра, вы можете использовать Dictionary или Hashtable в качестве кеша - данный параметр (ключ) вы сохраните это значение. Вы можете иметь каждую запись как WeakReference для значения, поэтому, когда значение не упоминается нигде, и происходит сбор мусора, память будет освобождена.

Надеюсь, что это поможет.

Answer 2

Нет, поэтому вы должны использовать Lazy<T> для реализации расчета JIT.

Answer 3

В моем понимании нет неявного кэширования - вы должны кэшировать значение данного свойства себя первый раз, когда он рассчитывается

Например:

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

Answer 4

Вопрос очень неясен, для меня не очевидно, как связаны геттер и фрагмент под ним. Но да, аксессоры свойств обычно сильно оптимизированы. Не компилятором C#, компилятором JIT. Во-первых, они часто встроены, поэтому вы не платите за стоимость вызова метода.

Это произойдет только в том случае, если геттер не содержит слишком много кода и не обезьяна с блокировками и обработкой исключений. Вы можете помочь JIT компилятор оптимизировать общий случай с кодом, как это:

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

Это будет встраивать общий случай и дать метод создания оставаться не-встраиваемыми. Обычно это скомпилировано в три команды машинного кода в сборке Release (load + test + jump), примерно на nano-second времени выполнения. Это микро-оптимизация, поскольку фактическое совершенство перфорации было бы довольно редко.

Обратите внимание, что данный пример кода не является потокобезопасным. Всегда сначала пишите правильный код, а не быстрый код.