Optimizing Performance: Data Binding
.NET Framework 4.5
Windows Presentation Foundation (WPF) data binding provides a simple and consistent way for applications to present and interact with data. Elements can be bound to data from a variety of data sources in the form of CLR objects and XML.
This topic provides data binding performance recommendations.
This topic contains the following sections.
- How Data Binding References are Resolved
- Binding to Large CLR Objects
- Binding to an ItemsSource
- Bind IList to ItemsControl not IEnumerable
- Do not Convert CLR objects to XML Just for Data Binding.
- Related Topics
How Data Binding References are Resolved
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 aPropertyDescriptor. 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.
Binding the Text property of a TextBlock
Binding time (ms)
Render time -- includes binding (ms)
To a property of a CLR object
115
314
To a property of a CLR object which implements INotifyPropertyChanged
115
305
To a DependencyProperty of a DependencyObject.
90
263
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.
Data binding 1000 TextBlock objects
Binding time (ms)
Render time -- includes binding (ms)
To a CLR object with 1000 properties
950
1200
To 1000 CLR objects with one property
115
314
Consider a scenario in which you have a CLR List<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 ItemsSourceproperty 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<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<T>. An ObservableCollection<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<T> object is bound to ListBox element'sItemsSource. The number in the second row represents the elapsed time when an ObservableCollection<T> is bound to the ListBox element's ItemsSource. Note the significant time savings using the ObservableCollection<T> data binding strategy.
Data binding the ItemsSource
Update time for 1 item (ms)
To a CLR List<T> object
1656
To an ObservableCollection<T>
20
Bind IList to ItemsControl not IEnumerable
If you have a choice between binding an IList<T> or an IEnumerable to an ItemsControl object, choose the IList<T> object. Binding IEnumerable to an ItemsControl forces WPF to create a wrapper IList<T> object, which means your performance is impacted by the unnecessary overhead of a second object.
Do not Convert CLR objects to XML Just for Data Binding.
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.