WPF performance and .NET Framework Client Profile related blogs provided by Jossef Goldberg.
We sometimes hear concerns that WPF applications memory foot print is too large.
This could be because of many reasons, but a common reason is that the application simply contains large number of elements in its visual tree. Very large tree will increase memory consumption and cause severe sluggishness.
Very often the root cause is that Virtualization got turned off. As you know Virtualization is on by default in WPF ListBox & ListView controls, but certain conditions can turn it off (see conditions below) even if you did not intent to!
Another possible cause is that the application uses rich templates that can quickly causes elements count to grow.
A good tool that can help you isolate these kinds of issues is Snoop.
In the image below, you can see that the app is using the Virtualizes Stack panel, however you can see that the ListBox contains thousand of elements, not as expected.
Snoop allows you to quickly filter properties, so if you type "IsGr" in the Property Filter box, you can see that the IsGrouping property is checked. In this example , the the application turned Grouping on, which causes Virtualization to be turned off.
As you may already know WPF has a built-in virtualizing panel called VirtualizingStackPanel that supports UI virtualization and lays out its elements like StackPanel.
The WPF ListBox & ListView controls use this panel by default. Other containers controls such as Canvas do not have virtualization support in .Net 3.0 & 3.5.
Chris Lovett from Microsoft now wrote a great sample that shows how you can also virtualize a Canvas container control so it can efficiently host and scroll thousands of WPF elements without consuming huge amount of memory.
The provided down-loadable ZIP has a white paper and the code.
Hope you find this useful.