| title | description | ms.date | dev_langs | helpviewer_keywords | ms.assetid | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
Optimizing Performance: Object Behavior |
Learn how to optimize the performance of object behavior in Windows Presentation Foundation (WPF) by understanding their intrinsic behavior. |
03/30/2017 |
|
|
73aa2f47-1d73-439a-be1f-78dc4ba2b5bd |
Understanding the intrinsic behavior of WPF objects will help you make the right tradeoffs between functionality and performance.
The delegate that an object passes to its event is effectively a reference to that object. Therefore, event handlers can keep objects alive longer than expected. When performing clean up of an object that has registered to listen to an object's event, it is essential to remove that delegate before releasing the object. Keeping unneeded objects alive increases the application's memory usage. This is especially true when the object is the root of a logical tree or a visual tree.
WPF introduces a weak event listener pattern for events that can be useful in situations where the object lifetime relationships between source and listener are difficult to keep track of. Some existing WPF events use this pattern. If you are implementing objects with custom events, this pattern may be of use to you. For details, see Weak Event Patterns.
There are several tools, such as the CLR Profiler and the Working Set Viewer, that can provides information on the memory usage of a specified process. The CLR Profiler includes a number of very useful views of the allocation profile, including a histogram of allocated types, allocation and call graphs, a time line showing garbage collections of various generations and the resulting state of the managed heap after those collections, and a call tree showing per-method allocations and assembly loads. For more information, see Performance.
In general, accessing a dependency property of a xref:System.Windows.DependencyObject is not slower than accessing a CLR property. While there is a small performance overhead for setting a property value, getting a value is as fast as getting the value from a CLR property. Offsetting the small performance overhead is the fact that dependency properties support robust features, such as data binding, animation, inheritance, and styling. For more information, see Dependency Properties Overview.
You should define dependency properties in your application very carefully. If your xref:System.Windows.DependencyProperty affects only render type metadata options, rather than other metadata options such as xref:System.Windows.FrameworkPropertyMetadata.AffectsMeasure%2A, you should mark it as such by overriding its metadata. For more information about overriding or obtaining property metadata, see Dependency Property Metadata.
It may be more efficient to have a property change handler invalidate the measure, arrange, and render passes manually if not all property changes actually affect measure, arrange, and render. For instance, you might decide to re-render a background only when a value is greater than a set limit. In this case, your property change handler would only invalidate render when the value exceeds the set limit.
By default, registered dependency properties are non-inheritable. However, you can explicitly make any property inheritable. While this is a useful feature, converting a property to be inheritable impacts performance by increasing the length of time for property invalidation.
While calling xref:System.Windows.EventManager.RegisterClassHandler%2A allows you to save your instance state, it is important to be aware that the handler is called on every instance, which can cause performance problems. Only use xref:System.Windows.EventManager.RegisterClassHandler%2A when your application requires that you save your instance state.
When creating a xref:System.Windows.DependencyProperty that requires a default value, set the value using the default metadata passed as a parameter to the xref:System.Windows.DependencyProperty.Register%2A method of the xref:System.Windows.DependencyProperty. Use this technique rather than setting the property value in a constructor or on each instance of an element.
When creating a xref:System.Windows.DependencyProperty, you have the option of setting the xref:System.Windows.PropertyMetadata using either the xref:System.Windows.DependencyProperty.Register%2A or xref:System.Windows.DependencyProperty.OverrideMetadata%2A methods. Although your object could have a static constructor to call xref:System.Windows.DependencyProperty.OverrideMetadata%2A, this is not the optimal solution and will impact performance. For best performance, set the xref:System.Windows.PropertyMetadata during the call to xref:System.Windows.DependencyProperty.Register%2A.
A xref:System.Windows.Freezable is a special type of object that has two states: unfrozen and frozen. Freezing objects whenever possible improves the performance of your application and reduces its working set. For more information, see Freezable Objects Overview.
Each xref:System.Windows.Freezable has a xref:System.Windows.Freezable.Changed event that is raised whenever it changes. However, change notifications are costly in terms of application performance.
Consider the following example in which each xref:System.Windows.Shapes.Rectangle uses the same xref:System.Windows.Media.Brush object:
[!code-csharpPerformance#PerformanceSnippet2] [!code-vbPerformance#PerformanceSnippet2]
By default, WPF provides an event handler for the xref:System.Windows.Media.SolidColorBrush object's xref:System.Windows.Freezable.Changed event in order to invalidate the xref:System.Windows.Shapes.Rectangle object's xref:System.Windows.Shapes.Shape.Fill%2A property. In this case, each time the xref:System.Windows.Media.SolidColorBrush has to fire its xref:System.Windows.Freezable.Changed event it is required to invoke the callback function for each xref:System.Windows.Shapes.Rectangle—the accumulation of these callback function invocations impose a significant performance penalty. In addition, it is very performance intensive to add and remove handlers at this point since the application would have to traverse the entire list to do so. If your application scenario never changes the xref:System.Windows.Media.SolidColorBrush, you will be paying the cost of maintaining xref:System.Windows.Freezable.Changed event handlers unnecessarily.
Freezing a xref:System.Windows.Freezable can improve its performance, because it no longer needs to expend resources on maintaining change notifications. The table below shows the size of a simple xref:System.Windows.Media.SolidColorBrush when its xref:System.Windows.Freezable.IsFrozen%2A property is set to true, compared to when it is not. This assumes applying one brush to the xref:System.Windows.Shapes.Shape.Fill%2A property of ten xref:System.Windows.Shapes.Rectangle objects.
| State | Size |
|---|---|
| Frozen xref:System.Windows.Media.SolidColorBrush | 212 Bytes |
| Non-frozen xref:System.Windows.Media.SolidColorBrush | 972 Bytes |
The following code sample demonstrates this concept:
[!code-csharpPerformance#PerformanceSnippet3] [!code-vbPerformance#PerformanceSnippet3]
The delegate that an object passes to a xref:System.Windows.Freezable object's xref:System.Windows.Freezable.Changed event is effectively a reference to that object. Therefore, xref:System.Windows.Freezable.Changed event handlers can keep objects alive longer than expected. When performing clean up of an object that has registered to listen to a xref:System.Windows.Freezable object's xref:System.Windows.Freezable.Changed event, it is essential to remove that delegate before releasing the object.
WPF also hooks up xref:System.Windows.Freezable.Changed events internally. For example, all dependency properties which take xref:System.Windows.Freezable as a value will listen to xref:System.Windows.Freezable.Changed events automatically. The xref:System.Windows.Shapes.Shape.Fill%2A property, which takes a xref:System.Windows.Media.Brush, illustrates this concept.
[!code-csharpPerformance#PerformanceSnippet4] [!code-vbPerformance#PerformanceSnippet4]
On the assignment of myBrush to myRectangle.Fill, a delegate pointing back to the xref:System.Windows.Shapes.Rectangle object will be added to the xref:System.Windows.Media.SolidColorBrush object's xref:System.Windows.Freezable.Changed event. This means the following code does not actually make myRect eligible for garbage collection:
[!code-csharpPerformance#PerformanceSnippet5] [!code-vbPerformance#PerformanceSnippet5]
In this case myBrush is still keeping myRectangle alive and will call back to it when it fires its xref:System.Windows.Freezable.Changed event. Note that assigning myBrush to the xref:System.Windows.Shapes.Shape.Fill%2A property of a new xref:System.Windows.Shapes.Rectangle will simply add another event handler to myBrush.
The recommended way to clean up these types of objects is to remove the xref:System.Windows.Media.Brush from the xref:System.Windows.Shapes.Shape.Fill%2A property, which will in turn remove the xref:System.Windows.Freezable.Changed event handler.
[!code-csharpPerformance#PerformanceSnippet6] [!code-vbPerformance#PerformanceSnippet6]
WPF also provides a variation of the xref:System.Windows.Controls.StackPanel element that automatically "virtualizes" data-bound child content. In this context, the word virtualize refers to a technique by which a subset of objects are generated from a larger number of data items based upon which items are visible on-screen. It is intensive, both in terms of memory and processor, to generate a large number of UI elements when only a few may be on the screen at a given time. xref:System.Windows.Controls.VirtualizingStackPanel (through functionality provided by xref:System.Windows.Controls.VirtualizingPanel) calculates visible items and works with the xref:System.Windows.Controls.ItemContainerGenerator from an xref:System.Windows.Controls.ItemsControl (such as xref:System.Windows.Controls.ListBox or xref:System.Windows.Controls.ListView) to only create elements for visible items.
As a performance optimization, visual objects for these items are only generated or kept alive if they are visible on the screen. When they are no longer in the viewable area of the control, the visual objects may be removed. This is not to be confused with data virtualization, where data objects are not all present in the local collection- rather streamed in as needed.
The table below shows the elapsed time adding and rendering 5000 xref:System.Windows.Controls.TextBlock elements to a xref:System.Windows.Controls.StackPanel and a xref:System.Windows.Controls.VirtualizingStackPanel. In this scenario, the measurements represent the time between attaching a text string to the xref:System.Windows.Controls.ItemsControl.ItemsSource%2A property of an xref:System.Windows.Controls.ItemsControl object to the time when the panel elements display the text string.
| Host panel | Render time (ms) |
|---|---|
| xref:System.Windows.Controls.StackPanel | 3210 |
| xref:System.Windows.Controls.VirtualizingStackPanel | 46 |