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

时间:2012-03-22 12:20:31

标签: wpf performance blend

我列出了所有可以帮助改善具有大量控件的非常复杂的应用程序中的性能的列表。如果你想加你的,欢迎你!

  • 如果您知道控件的大小,请删除“自动”并输入实际值,这样父级就不必解析所有子级以检查所需的大小
  • 如果元素不需要是交互式的,则设置参数IsHitTestVisible = False
  • 冻结所有可以
  • 的对象
  • 使用静态资源而不是动态资源
  • 不要使用Ellipse对象,将Ellipse转换为Path
  • 如果可以使用TextBlock
  • ,请不要使用TextBox或Label
  • 尽可能使用Canvas而不是Grid
  • No FlowDocument
  • 虚拟化!! VirtualizingStackPanel而不是StackPanel
  • 不要使用List,ObservableCollection更快
  • 使用绘图库,它比形状库
  • 更快
  • 检查你的装订!如果绑定不起作用,则可能非常慢
  • 请勿使用Visibility.Hidden,否则请使用Visibility.Collapsed
  • DependencyProperty比INotifyPropertyChanged
  • 快3倍
  • StreamGeometry比PathGeometry
  • 完成后清除事件处理程序!
  • 如果可以,请不要使用“对象不透明度”属性,使用其颜色不透明度
  • 检查您的应用程序是否为硬件渲染(第2层)
  • 当您可以
  • 时缩小图像的尺寸/质量
  • 渲染图像比渲染矢量更快!

我使用的工具:

  • WPF检查员
  • 探听
  • WPFPerf套件
  • Visual Studio分析器
  • 适用于.NET的CLR Profiler

1 个答案:

答案 0 :(得分:0)

这实际上是一个评论,而不是答案,但没有足够的空间。

ObservableCollection比List更快的方式对我来说似乎很直观,因为ObservableCollection实现了iList。

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

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

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

    1510 List
    1780 Dictionary  
    1820 HashSet
    1980 ObservableCollection
    8000 SortedDictionary

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

归结为功能。 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毫秒。访问时间是一个死热,可重复。