Before discussing data binding performance issues, it is worthwhile to explore how the Windows Presentation Foundation (WPF) data binding engine resolves object references for binding.

The source of a Windows Presentation Foundation (WPF) data binding can be any CLR object. You can bind to properties, sub-properties, or indexers of a CLR object. The binding references are resolved by using either Microsoft .NET Framework reflection or an ICustomTypeDescriptor. Here are three methods for resolving object references for binding.

The first method involves using reflection. In this case, the PropertyInfo object is used to discover the attributes of the property and provides access to property metadata. When using the ICustomTypeDescriptor interface, the data binding engine uses this interface to access the property values. The ICustomTypeDescriptor interface is especially useful in cases where the object does not have a static set of properties.

Property change notifications can be provided either by implementing the INotifyPropertyChanged interface or by using the change notifications associated with the TypeDescriptor. However, the preferred strategy for implementing property change notifications is to use INotifyPropertyChanged.

If the source object is a CLR object and the source property is a CLR property, the Windows Presentation Foundation (WPF) data binding engine has to first use reflection on the source object to get the TypeDescriptor, and then query for a PropertyDescriptor. This sequence of reflection operations is potentially very time-consuming from a performance perspective.

The second method for resolving object references involves a CLR source object that implements the INotifyPropertyChanged interface, and a source property that is a CLR property. In this case, the data binding engine uses reflection directly on the source type and gets the required property. This is still not the optimal method, but it will cost less in working set requirements than the first method.

The third method for resolving object references involves a source object that is a DependencyObject and a source property that is a DependencyProperty. In this case, the data binding engine does not need to use reflection. Instead, the property engine and the data binding engine together resolve the property reference independently. This is the optimal method for resolving object references used for data binding.

The table below compares the speed of data binding the Text property of one thousand TextBlock elements using these three methods.

There is a significant performance impact when you data bind to a single CLR object with thousands of properties. You can minimize this impact by dividing the single object into multiple CLR objects with fewer properties. The table shows the binding and rendering times for data binding to a single large CLR object versus multiple smaller objects.

Consider a scenario in which you have a CLR List<(Of <(T>)>) object that holds a list of employees that you want to display in a ListBox. To create a correspondence between these two objects, you would bind your employee list to the ItemsSource property of the ListBox. However, suppose you have a new employee joining your group. You might think that in order to insert this new person into your bound ListBox values, you would simply add this person to your employee list and expect this change to be recognized by the data binding engine automatically. That assumption would prove false; in actuality, the change will not be reflected in the ListBox automatically. This is because the CLR List<(Of <(T>)>) object does not automatically raise a collection changed event. In order to get the ListBox to pick up the changes, you would have to recreate your list of employees and re-attach it to the ItemsSource property of the ListBox. While this solution works, it introduces a huge performance impact. Each time you reassign the ItemsSource of ListBox to a new object, the ListBox first throws away its previous items and regenerates its entire list. The performance impact is magnified if your ListBox maps to a complex DataTemplate.

A very efficient solution to this problem is to make your employee list an ObservableCollection<(Of <(T>)>). An ObservableCollection<(Of <(T>)>) object raises a change notification which the data binding engine can receive. The event adds or removes an item from an ItemsControl without the need to regenerate the entire list.

The table below shows the time it takes to update the ListBox (with UI virtualization turned off) when one item is added. The number in the first row represents the elapsed time when the CLR List<(Of <(T>)>) object is bound to ListBox element's ItemsSource. The number in the second row represents the elapsed time when an ObservableCollection<(Of <(T>)>) is bound to the ListBox element's ItemsSource. Note the significant time savings using the ObservableCollection<(Of <(T>)>) data binding strategy.

If you have a choice between binding an IList<(Of <(T>)>) or an IEnumerable to an ItemsControl object, choose the IList<(Of <(T>)>) object. Binding IEnumerable to an ItemsControl forces WPF to create a wrapper IList<(Of <(T>)>) object, which means your performance is impacted by the unnecessary overhead of a second object.

WPF allows you to data bind to XML content; however, data binding to XML content is slower than data binding to CLR objects. Do not convert CLR object data to XML if the only purpose is for data binding.

Concepts