解决 WPF 应用程序的性能问题 [英] Solve performance issue with WPF application
问题描述
我列出了可以帮助提高具有大量控件的非常复杂的应用程序的性能的所有内容.如果你想添加你的，欢迎！
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!
- 如果你知道控件的大小，去掉 Auto 并输入实际值，这样父级就不必解析所有子级来检查他需要的大小
- 如果元素不需要交互，则设置参数 IsHitTestVisible=False
- 冻结所有可以冻结的对象
- 使用静态资源代替动态资源
- 不要使用 Ellipse 对象，将 Ellipse 转换为路径
- 如果可以使用 TextBlock，请不要使用 TextBox 或 Label
- 尽可能使用 Canvas 而不是 Grid
- 无流程文档
- 虚拟化！！VirtualizingStackPanel 而不是 StackPanel
- 不要使用 List，ObservableCollection 会更快
- 使用绘图库，它比形状库更快
- 检查您的绑定！如果绑定不起作用，它可能会很慢
- 不要使用 Visibility.Hidden，尽可能使用 Visibility.Collapsed
- DependencyProperty 比 INotifyPropertyChanged 快 3 倍
- StreamGeometry 比 PathGeometry 快
- 完成处理后清除事件处理程序！
- 不要使用对象不透明度属性，如果可以，请使用他的颜色不透明度
- 检查您的应用程序是否为硬件渲染(第 2 层)
- 尽可能缩小图片的尺寸/质量
- 渲染图像比渲染矢量快得多！
我使用的工具:
- WPF 检查器
- 窥探
- WFPPerf 套件
- Visual Studio 分析器
- 用于 .NET 的 CLR 分析器
推荐答案
这确实是一条评论，而不是答案，但评论中的空间不足.
This is really a comment and not an answer but not enough space in commment.
ObservableCollection 比 List 更快的方式对我来说似乎违反直觉，因为 ObservableCollection 实现了 iList.
ObservableCollection way faster than List seemed counter intuitive to me as ObservableCollection implements iList.
我有一个 660,000 个单词的列表，我在 ListView 上测试过(虚拟化).创建了下面的集合类型并创建了按钮以在后面的代码中切换绑定.即时呈现所有集合(虚拟化的力量).
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).
变量是从集合中创建您需要的集合和特征的时间.使用 SQLdataReader 填充集合.SQLdataReader 中存在可变性.每运行 10 次得到 2 个有效数字的可重复结果，我将平均值报告为 3 个有效数字.List 比 ObservableCollection 快了大约 400 毫秒.没有测量内存，但 List 显然会使用更少的内存.
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.
加载 660,000 个字符串的毫秒数，平均每个字符串大约 40 个字符.
Milliseconds to load 660,000 strings averaging about 40 character each.
1510 List
1780 Dictionary
1820 HashSet
1980 ObservableCollection
8000 SortedDictionary
在一个非常大的集合中，HashSet 会比 List 更好.HashSet 应该击败 Dictionary - 这些数字在这个有限的非严格测试的可变性范围内.
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.
这归结为功能.ObservableCollection 支持动态插入和删除.如果您需要动态插入和删除，那么它是迄今为止最好的选择.如果不需要动态插入和删除，我的经验是List是更好的选择(通过ListItem List的iNotifyPropertyChanged支持动态修改).
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 保留项目添加的顺序.HashSet 不保留顺序.选择使用哪个集合的因素很多.http:///geekswithblogs.net/BlackRabbitCoder/archive/2011/06/16/c.net-fundamentals-choosing-the-right-collection-class.aspx
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
对单个项目的访问时间发表了评论.我使用 List、ObservableCollection 和 Dictionary 访问了项目 [1]、[100000]、[200000]、[300000]、[400000]、[500000]、[600000].它们都是 12 毫秒.访问时间是死热和可重复的.
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.
这篇关于解决 WPF 应用程序的性能问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
