Optimizing Performance: Object Behavior

Article
02/04/2013

Understanding the intrinsic behavior of WPF objects will help you make the right tradeoffs between functionality and performance.

This topic contains the following sections.

Not Removing Event Handlers on Objects may Keep Objects Alive
Dependency Properties and Objects
Freezable Objects
User Interface Virtualization
Related Topics

Not Removing Event Handlers on Objects may Keep Objects Alive

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 .NET Framework Developer Center.

Dependency Properties and Objects

In general, accessing a dependency property of a 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.

DependencyProperty Optimizations

You should define dependency properties in your application very carefully. If your DependencyProperty affects only render type metadata options, rather than other metadata options such as AffectsMeasure, 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.

Making a DependencyProperty Inheritable is Not Free

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.

Use RegisterClassHandler Carefully

While calling RegisterClassHandler 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 RegisterClassHandler when your application requires that you save your instance state.

Set the Default Value for a DependencyProperty during Registration

When creating a DependencyProperty that requires a default value, set the value using the default metadata passed as a parameter to the Register method of the DependencyProperty. Use this technique rather than setting the property value in a constructor or on each instance of an element.

Set the PropertyMetadata Value using Register

When creating a DependencyProperty, you have the option of setting the PropertyMetadata using either the Register or OverrideMetadata methods. Although your object could have a static constructor to call OverrideMetadata, this is not the optimal solution and will impact performance. For best performance, set the PropertyMetadata during the call to Register.

Freezable Objects

A 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 Freezable has a 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 Rectangle uses the same Brush object:

            rectangle_1.Fill = myBrush
            rectangle_2.Fill = myBrush
            rectangle_3.Fill = myBrush
            ' ...
            rectangle_10.Fill = myBrush

rectangle_1.Fill = myBrush;
rectangle_2.Fill = myBrush;
rectangle_3.Fill = myBrush;
// ...
rectangle_10.Fill = myBrush;

By default, WPF provides an event handler for the SolidColorBrush object's Changed event in order to invalidate the Rectangle object's Fill property. In this case, each time the SolidColorBrush has to fire its Changed event it is required to invoke the callback function for each 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 SolidColorBrush, you will be paying the cost of maintaining Changed event handlers unnecessarily.

Freezing a 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 SolidColorBrush when its IsFrozen property is set to true, compared to when it is not. This assumes applying one brush to the Fill property of ten Rectangle objects.

State	Size
Frozen SolidColorBrush	212 Bytes
Non-frozen SolidColorBrush	972 Bytes

The following code sample demonstrates this concept:

            Dim frozenBrush As Brush = New SolidColorBrush(Colors.Blue)
            frozenBrush.Freeze()
            Dim nonFrozenBrush As Brush = New SolidColorBrush(Colors.Blue)

            For i As Integer = 0 To 9
                ' Create a Rectangle using a non-frozed Brush.
                Dim rectangleNonFrozen As New Rectangle()
                rectangleNonFrozen.Fill = nonFrozenBrush

                ' Create a Rectangle using a frozed Brush.
                Dim rectangleFrozen As New Rectangle()
                rectangleFrozen.Fill = frozenBrush
            Next i

Brush frozenBrush = new SolidColorBrush(Colors.Blue);
frozenBrush.Freeze();
Brush nonFrozenBrush = new SolidColorBrush(Colors.Blue);

for (int i = 0; i < 10; i++)
{
    // Create a Rectangle using a non-frozed Brush.
    Rectangle rectangleNonFrozen = new Rectangle();
    rectangleNonFrozen.Fill = nonFrozenBrush;

    // Create a Rectangle using a frozed Brush.
    Rectangle rectangleFrozen = new Rectangle();
    rectangleFrozen.Fill = frozenBrush;
}

Changed Handlers on Unfrozen Freezables may Keep Objects Alive

The delegate that an object passes to a Freezable object's Changed event is effectively a reference to that object. Therefore, Changed event handlers can keep objects alive longer than expected. When performing clean up of an object that has registered to listen to a Freezable object's Changed event, it is essential to remove that delegate before releasing the object.

WPF also hooks up Changed events internally. For example, all dependency properties which take Freezable as a value will listen to Changed events automatically. The Fill property, which takes a Brush, illustrates this concept.

            Dim myBrush As Brush = New SolidColorBrush(Colors.Red)
            Dim myRectangle As New Rectangle()
            myRectangle.Fill = myBrush

Brush myBrush = new SolidColorBrush(Colors.Red);
Rectangle myRectangle = new Rectangle();
myRectangle.Fill = myBrush;

On the assignment of myBrush to myRectangle.Fill, a delegate pointing back to the Rectangle object will be added to the SolidColorBrush object's Changed event. This means the following code does not actually make myRect eligible for garbage collection:

            myRectangle = Nothing

myRectangle = null;

In this case myBrush is still keeping myRectangle alive and will call back to it when it fires its Changed event. Note that assigning myBrush to the Fill property of a new Rectangle will simply add another event handler to myBrush.

The recommended way to clean up these types of objects is to remove the Brush from the Fill property, which will in turn remove the Changed event handler.

            myRectangle.Fill = Nothing
            myRectangle = Nothing

myRectangle.Fill = null;
myRectangle = null;

User Interface Virtualization

WPF also provides a variation of the 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. VirtualizingStackPanel (through functionality provided by VirtualizingPanel) calculates visible items and works with the ItemContainerGenerator from an ItemsControl (such as ListBox or 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 TextBlock elements to a StackPanel and a VirtualizingStackPanel. In this scenario, the measurements represent the time between attaching a text string to the ItemsSource property of an ItemsControl object to the time when the panel elements display the text string.

Host panel	Render time (ms)
StackPanel	3210
VirtualizingStackPanel	46