9

I've made a list of everything that can helps to improve performance in a very complex application with a lot of controls. If you want to add yours, your welcome!

  • If you know the size of the control, remove the Auto and enter the real value, so the parent doesn't have to parse all childs to check the size he needs
  • Set the parameter IsHitTestVisible=False if the element doesn't need to be interactive
  • Freeze all object that you can
  • Use Static resources instead of Dynamic resources
  • Don't use the Ellipse object, transform the Ellipse to a Path
  • Don't use TextBox or Label if you can use a TextBlock
  • Use Canvas instead of Grid when possible
  • No FlowDocument
  • Virtualize!! VirtualizingStackPanel instead of StackPanel
  • Don't use List, the ObservableCollection is way faster
  • Use the Drawing library, it's faster then the Shapes library
  • Check your binding! If a binding doesn't works, it can be very slow
  • Don't use Visibility.Hidden, use Visibility.Collapsed when you can
  • DependencyProperty is 3x faster then INotifyPropertyChanged
  • StreamGeometry is faster then PathGeometry
  • Clear Event Handlers when you've done with them!
  • Don't use the Object Opacity property, if you can, use his color opacity
  • Check if your application is Hardware rendering (Tier-2)
  • Reduce size/quality of your image when you can
  • Rendering image is way faster then rendering vector!

Tools that I use:

  • WPF Inspector
  • Snoop
  • WPFPerf suite
  • Visual Studio profiler
  • CLR Profiler for .NET
mlemay
  • 1,622
  • 2
  • 32
  • 53
  • 2
    I'm afraid it doesn't fit well in a Q&A website such as stackoverflow. – ken2k Mar 22 '12 at 16:28
  • It's not a question, it's an answer if someone is looking for help about performance in WPF. I was looking for a subject like this for about a month and if I can help someone after all my test and research, I'll be happy – mlemay Mar 22 '12 at 16:44
  • I Googled WPF Performance Optimization and got the following http://msdn.microsoft.com/en-us/library/aa970683.aspx http://www.michaelflanakin.com/Weblog/tabid/142/articleType/ArticleView/articleId/1015/WPF-Performance-Tips.aspx – paparazzo Mar 22 '12 at 18:20
  • You should have just posted a one-liner question and post this as the answer so it wouldn't get closed ... anyway tx for the tips – Rado Sep 11 '13 at 13:47

1 Answers1

0

This is really a comment and not an answer but not enough space in commment.

ObservableCollection way faster than List seemed counter intuitive to me as ObservableCollection implements iList.

I have a list of 660,000 words that I tested on a ListView (virtualizing). Created the collection types below and created buttons to switch the binding in code behind. All collections rendered instantaneously (the power of virtualiztion).

The variable is the time to create the collection and features you need from the collection. Used SQLdataReader to populate the collection. There is variability in the SQLdataReader. Ran each 10 times got repeatable results to 2 significant digits and I report the average to 3 significant digits. List beat ObservableCollection by about 400 milliseconds. Did not measure memory but List clearly is going to use less memory.

Milliseconds to load 660,000 strings averaging about 40 character each.

    1510 List
    1780 Dictionary  
    1820 HashSet
    1980 ObservableCollection
    8000 SortedDictionary

In a very large collection HashSet would fair better than List. HashSet should beat Dictionary - those numbers are within the variability of this limited non-rigorous test.

It comes down to features. ObservableCollection supports dynamic insert and delete. If you need dynamic insert and delete then it is by far the best choice. If you don't need dynamic insert and delete then my experience is that List is a better choice (via iNotifyPropertyChanged of the ListItem List supports dynamic revision).

List retains the order the items are added. HashSet does not retain the order. Many factors in selecting which collection to use. http://geekswithblogs.net/BlackRabbitCoder/archive/2011/06/16/c.net-fundamentals-choosing-the-right-collection-class.aspx

Had a comment about access time to a single item. I accessed items [1],[100000],[200000],[300000],[400000],[500000],[600000] using List, ObservableCollection, and Dictionary. They were all 12 ms. Access time was a dead heat and repeatable.

paparazzo
  • 44,497
  • 23
  • 105
  • 176
  • i think he meant: "Don't bind a List as ItemsSource to your ItemsControl, ObservableCollection is way faster" :) Not that the ObservableCollection is itself a fast container. – dowhilefor Mar 22 '12 at 16:34
  • The problem is not on the loading, ok it will be faster with the List, but after that to access a single element in the List, it's slower than the ObservableCollection (List is 90x slower at this point) – mlemay Mar 22 '12 at 17:22
  • OK I will look at access time to a single element. – paparazzo Mar 22 '12 at 17:27
  • @mlemay Access time is a dead heat in my test. 12 ms to access 7 items by ordinal position. – paparazzo Mar 22 '12 at 17:52