Влияние производительности пути привязки Wpf = {x: Статический <propertypath>}?

Question

У меня есть свойство экземпляра CLR, статический PropertyPath, который указывает на свойство экземпляра, и привязка xaml, которая использует статический PropertyPath напрямую, вот так:

NB: GetPropertyPath - это просто метод, который возвращает основанный на propertypathдля данного выражения linq из имени члена.

<Code>

    public static PropertyPath MyPropertyPath = GetPropertyPath(p=> p.MyProperty);

    private object _myProperty;

    public object MyProperty
    {
       get{ return _myProperty;}
       set 
       {
         _myProperty = value;
         OnPropertyChanged(MyPropertyPath.Path);
      }
    }

</Code>

Затем с MyViewModel в качестве datacontext стандартным способом mvvm привязка xaml задается как:

<Code> 
    {Binding Path={x:Static myNamespace:MyViewModel.MyPropertyPath}}
</Code>

Этот подход имеет большое преимуществопоскольку код не использует никаких ссылок, которые не проверяются как часть сборки.Если что-то изменилось в коде модели представления, ошибка привязок xaml при сборке, если они больше не верны.

Мой вопрос заключается в том, знает ли кто-нибудь о каких-либо негативных воздействиях на производительность, которые этот подход мог бы оказать?

Answer 1

Я думаю, что влияние GetPropertyPath () было бы здесь пренебрежимо мало, поскольку я держу результат в статической переменной, а не вызываю его несколько раз, как это требуется для использования OnPropertyChanged (Expression> expression) напрямую.

Я, однако, немного запутался во внутренностях привязки данных, может ли предоставление пути свойства x: Static непосредственно к xaml обеспечить какое-либо улучшение производительности? Я ухудшаю производительность, используя x: static?

Answer 2

Некоторое время назад мы протестировали только первую часть вашего вопроса.Какая разница в производительности между OnPropertyChanged(string propertyName) и OnPropertyChanged(Expression<Func<object>> expression)?Последний аналогичен вашему GetPropertyPath() методу, и он был в ~ 2,5 раза медленнее, чем исходный метод на основе строк (569 мс против 1464 мс на 1 000 000 итераций).Это не кажется огромной ценой за ясность кода, хотя не следует пренебрегать влиянием памяти при использовании Expressions.

Моя общая рекомендация - использовать выражения в неинтенсивных вычислениях и избегать их в противном случае.Я никогда не замечал узкого места в этой конкретной части кода - всегда есть что-то значительно более медленное ...