【转】WPF Performance and .NET Framework Client Profile

origin: http://blogs.msdn.com/b/jgoldb/archive/2010/06/14/memory-leak-hotfixes-for-wpf-3-5-sp1.aspx

 

 

Hopefully folks saw my related blog post Finding Memory Leaks in WPF-based applications .
In this post below I wanted folks to be aware that we released few other KB Articles (Hotfix) that address other various memory leaks reported in .NET 3.5 SP1. Some of these fixes made it to .NET 4.

1. KB981107 (See: http://support.microsoft.com/kb/981107)

This Hotfix fixes the following memory leaks in .NET 3.5 SP1 WPF-based applications.
Issue 1:
This affects an app that contains styles or templates that refer to application resources (via StaticResource or DynamicResource), and that creates a large number of elements that use these styles or templates but never need the actual value of the resource.  In this situation, the app can leak DeferredAppResourceReference objects, even after the elements themselves have been reclaimed.  (In addition, the app can leak WeakReferences and array space, similar to the issues described below.)

An example:  App resources define   <sys:Double x:Key="{x:Static SystemParameters.HorizontalScrollBarHeightKey}">20</sys:Double>     This creates a resource that's used by any control that can display a horizontal scrollbar.  Creating a large number of such controls that never actually display their scrollbar will encounter the leak.

Issue 2:
This affects an app that creates a large number of short-lived elements with properties that are data-bound to a DependencyProperty of longer-lived elements. In this situation, the longer-lived elements maintain lists of WeakReference objects, used to notify the short-lived elements about property changes. The app can leak WeakReference objects and the array space to hold them, even after the short-lived elements have been reclaimed.

An example:   ListBoxItem binds its HorizontalContentAlignment property to a similar property on its governing ListBox.   An app that creates a large number of ListBoxItems (say by doing a large number of additions and deletions to the ListBox's ItemsSource) will encounter the leak.

Issue 3:
This issue affects classes derived from TreeView or Selector (including ListBox, ListView, Menu, DataGrid, and many others).   These classes register for an internal notification from the KeyboardNavigation class, used for controlling keyboard focus.   An app that creates a large number of these elements can leak WeakReference objects and the array space to hold them, even after the elements themselves have been reclaimed.
An example:  An app that creates a large number of short-lived ListBoxes will encounter the leak.  This can happen in a nested scenario, where an outer ListBox displays a collection that undergoes a large number of additions and deletions, and where each item is displayed using an inner ListBox.

These fixes are not included in NET4. We are considering this Hotfix also for NET4, but this decision has not been made, so stay tune.

2. KB967634: (See: http://support.microsoft.com/kb/967634 )

This fixes a memory leaks in .NET 3.5 SP1 WPF-based applications when using software 3D rendering involving a VisualBrush or DrawingBrush.
This fix is already included in .NET 4.

3. KB967328 (See: http://support.microsoft.com/Default.aspx?kbid=967328)

This Hotfix fixes memory leaks when a deferred resource isn't inflated due to the resource reference expression hooking up to the Inflated event on the resource dictionary entry.
If the resource dictionary is an application or theme dictionary, then these are essentially global and can cause these expressions to stay alive.
There are some discussions on this issue here.
This fix is already included in .NET 4.