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.
In summary:
PingBack from http://msdnrss.thecoderblogs.com/2008/03/25/quick-tips-to-improve-wpf-app-memory-footprint/
Возможности WPF по виртуализации визуального дерева вашего интерфейса.
Știați că în WPF: un buton poate conține un meniu ale cărui menu item-s pot c
Snoop はWPFアプリケーションのVisualツリーを確認できるツールです。特に多数の要素によってメモリーが消費されていないかどうかを確認する場合などに有効です。 WPF Performanceのブログ
If you could do your grouping in the ViewModel, then wouldn't this prevent virtualization from being turned off?
It seems to me that the problem is that ItemsControl is effectively creating its own backing store when IsGrouping is set to true, rather than having the ItemsSource be the backing store.
Architecturally, do you think this could be something that can be fixed without creating new controls?