Performance impact of Wpf Binding Path={x:Static <propertypath>}?

Question

I have a CLR instance property, a static PropertyPath which points to the instance property and a xaml binding which uses the static PropertyPath directly like so:

NB: GetPropertyPath is simply a method which returns the propertypath based on the given linq expression from the member name.



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

    private object _myProperty;

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

Then with MyViewModel as the datacontext in standard mvvm fashion the xaml binding is given as:

 
    {Binding Path={x:Static myNamespace:MyViewModel.MyPropertyPath}}

This approach has major benefit as the code does not use any references which are not checked as part of the build. If something is changed in the viewmodel code the xaml bindings error at build if they are no longer correct.

My question is this, is anyone aware of any negative performance impacts this approach could possibly have?

Anvaka Anvaka · Accepted Answer · 2010-09-09T10:07:27

Some time ago we tested only the first part of your question. What's the performance difference between OnPropertyChanged(string propertyName) and OnPropertyChanged(Expression<Func<object>> expression)? The latter is something similar to your GetPropertyPath() method and it was ~2.5 times slower than raw string-based approach (569 ms vs 1464 ms on 1 000 000 iterations). This doesn't seem like a huge price for code clarity, though one should not neglect memory impact when Expressions are used.

My general recommendation is to use Expressions in non-intensive calculations, and avoid them otherwise. I never spotted a bottleneck in this particular part of code - there is always something significantly slower...

Performance impact of Wpf Binding Path={x:Static <propertypath>}?

2 Answers