解决WPF应用程序的性能问题

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

如果元素不需要是交互式的,则设置参数IsHitTestVisible = False

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

不要使用Ellipse对象,将Ellipse转换为Path

Don't use TextBox or Label if you can use a TextBlock

如果可以使用TextBlock,请不要使用TextBox或Label

Use Canvas instead of Grid when possible

尽可能使用Canvas而不是Grid

No FlowDocument
Virtualize!! VirtualizingStackPanel instead of StackPanel

虚拟化! VirtualizingStackPanel而不是StackPanel

Don't use List, the ObservableCollection is way faster

不要使用List,ObservableCollection更快

Use the Drawing library, it's faster then the Shapes library

使用绘图库,它比Shapes库更快

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

不要使用Visibility.Hidden,尽可能使用Visibility.Collapsed

DependencyProperty is 3x faster then INotifyPropertyChanged

DependencyProperty比INotifyPropertyChanged快3倍

StreamGeometry is faster then PathGeometry

StreamGeometry比PathGeometry快

Clear Event Handlers when you've done with them!

完成后清除事件处理程序!

Don't use the Object Opacity property, if you can, use his color opacity

不要使用Object Opacity属性,如果可以,请使用他的颜色不透明度

Check if your application is Hardware rendering (Tier-2)

检查您的应用程序是否为硬件渲染(第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

Visual Studio探查器

CLR Profiler for .NET

适用于.NET的CLR Profiler

1 个解决方案

#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.

ObservableCollection比List更快的方式似乎对我来说是直观的,因为ObservableCollection实现了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).

我在ListView(虚拟化)上测试了660,000个单词的列表。创建下面的集合类型并创建按钮以在代码后面切换绑定。所有集合即时呈现(虚拟化的力量)。

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.

变量是从集合中创建集合和功能所需的时间。使用SQLdataReader填充集合。 SQLdataReader存在可变性。每10次得到可重复的结果到2位有效数字,我将平均值报告为3位有效数字。列出节拍ObservableCollection约400毫秒。没有测量内存,但列表显然会使用更少的内存。

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

加载660,000个字符串的毫秒数,平均每个字符串大约40个字符。

    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.

在一个非常大的集合中,HashSet比List更好。 HashSet应该击败字典 - 这些数字在这种有限的非严格测试的可变性范围内。

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).

它归结为功能。 ObservableCollection支持动态插入和删除。如果您需要动态插入和删除,那么它是目前最好的选择。如果您不需要动态插入和删除,那么我的经验是List是更好的选择(通过ListItem List的iNotifyPropertyChanged支持动态修订)。

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

列表保留添加项目的顺序。 HashSet不保留订单。选择使用哪个集合的因素很多。 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.

有关于单个项目的访问时间的评论。我使用List,ObservableCollection和Dictionary访问了项目[1],[100000],[200000],[300000],[400000],[500000],[600000]。他们都是12毫秒。访问时间是一个死热,可重复。

#1