解决 WPF 应用程序的性能问题 [关闭]

Question

我列出了所有有助于提高具有大量控件的非常复杂的应用程序的性能的所有内容。如果你想添加你的，欢迎！

• 如果你知道控件的大小，去掉 Auto 并输入真实值，这样父级就不必解析所有子级来检查他需要的大小
• 如果元素不需要交互，则设置参数 IsHitTestVisible=False
• 冻结所有可以冻结的对象
• 使用静态资源而不是动态资源
• 不要使用 Ellipse 对象，将 Ellipse 转换为 Path
• 如果可以使用 TextBlock，请不要使用 TextBox 或 Label
• 尽可能使用 Canvas 而不是 Grid
• 没有流文档
• 虚拟化！！虚拟化StackPanel 而不是 StackPanel
• 不要使用 List，ObservableCollection 更快
• 使用绘图库，比形状库更快
• 检查您的绑定！如果绑定不起作用，它可能会很慢
• 不要使用 Visibility.Hidden，尽可能使用 Visibility.Collapsed
• DependencyProperty 比 INotifyPropertyChanged 快 3 倍
• StreamGeometry 比 PathGeometry 更快
• 完成后清除事件处理程序！
• 不要使用对象的不透明度属性，如果可以的话，使用他的颜色不透明度
• 检查您的应用程序是否为硬件渲染（第 2 层）
• 尽可能减小图像的大小/质量
• 渲染图像比渲染矢量快得多！

我使用的工具：

• WPF 检查员
• 窥探
• WPFPerf 套件
• Visual Studio 分析器
• .NET 的 CLR 分析器

Answer 1

这确实是评论而不是答案，但评论空间不足。

ObservableCollection 比 List 快的方式对我来说似乎违反直觉，因为 ObservableCollection 实现了 iList。

我有一个包含 660,000 个单词的列表，我在 ListView（虚拟化）上进行了测试。 在下面创建了集合类型并创建了按钮来切换后面代码中的绑定。所有集合都即时呈现（虚拟化的力量）。

变量是创建集合的时间和从集合中需要的功能。使用 SQLdataReader 填充集合。 SQLdataReader 存在可变性。跑每 10 次得到 2 个有效数字的可重复结果，我将平均值报告为 3 个有效数字。 List 比 ObservableCollection 快了大约 400 毫秒。没有测量内存，但 List 显然会使用更少的内存。

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

    1510 List
    1780 Dictionary  
    1820 HashSet
    1980 ObservableCollection
    8000 SortedDictionary

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

归结为功能。 ObservableCollection 支持动态插入和删除。如果您需要动态插入和删除，那么它是迄今为止最好的选择。如果您不需要动态插入和删除，那么我的经验是 List 是更好的选择（通过 ListItem List 的 iNotifyPropertyChanged 支持动态修订）。

列表保留添加项目的顺序。 HashSet 不保留顺序。选择要使用的集合的许多因素。 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 毫秒。访问时间是死气沉沉的，而且是可重复的。