Solve performance issue with WPF application [closed]

问题

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.

Closed 7 years ago.

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

回答1:

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.

来源：https://stackoverflow.com/questions/9822166/solve-performance-issue-with-wpf-application