WPF Grid控件性能对比

本文从环境配置、测试应用、基准指标到最终结果，对WPF平台下几款主流Grid控件的性能做了一次全景式的横向对比。当然，主角是ComponentOne的Grid系列，但也不乏其他竞品的同场竞技。

测试环境

这份基准测试建立于2016年6月，对照组使用了当时各家的最新试用版本。清单如下：

· System.Windows.Controls.DataGrid——来自PresentationFramework.dll的官方组件。

· ComponentOne WPF版C1FlexGrid，版本4.4.0.20162.514。

· ComponentOne WPF版C1DataGrid，版本4.4.0.20162.514，相对成熟完善。

· Syncfusion Essential Studio WPF版SfDataGrid，版本14.1400.0.41。

· RadGridView，来自Telerik，版本2016.2.503.40。

所有测试均运行在同一台ENVY-23一体机上。所有Grid控件统一尺寸、统一使用默认样式，以保证公平。

测试应用程序

基准程序本身很灵活：既可以单独执行单项测试，也可以将所有测试依次跑一遍。用户可以设定同一测试的重复次数，从而得到更稳定的均值——10次运行的结果，足以排除操作系统或其他应用带来的随机干扰。应用的界面如下图所示。

单独分析某个特定用例时，单独运行一个测试就非常方便。这里有个关键点：在进行不同测试间的横向对比时，运行过程中绝对不能调整窗口大小。显示尺寸会直接影响性能，大屏幕不仅要花更多时间处理布局渲染，还会占用虚拟控件等系统资源，进而拖慢其他事件。

测试结果会自动保存到工作目录下的Excel文件中。如果需要更详细的日志，可以去App.xaml.cs文件里取消输出到TraceListener的相关注释。

整个测试中最有趣的技术挑战，是如何准确测量异步UI更新过程中复杂操作的执行耗时。经过多次尝试，我们认为目前的方法最有效——它可以精准捕捉到Grid界面更新完成的那个瞬间。完整的源代码已经附上，欢迎下载体验，也期待大家反馈优化建议。

需要说明的是，我们不提供任何控件的二进制文件。如果你需要亲自运行应用，请下载我们WPF版本的试用版以及其他控件的试用版本。所有版本都提供30天免费试用，完全够用。

基准

所有测试均采用了ListCollectionView作为数据源，并通过一个业务对象填充数据。设计了十二种不同类型的列。

为了公平对比，我们对所有Grid设定了统一的条件：智能生成列、固定列宽、可在底部新行添加内容、隐藏分组与搜索面板、单元格可修改。

每个基准的测试步骤完全一致：先清除上一轮的所有界面元素，执行垃圾回收，等待所有析构操作完成；然后启动下一轮测试并重置秒表；按要求重复执行；最后统计总耗时并计算平均值。

详解各基准的实现

基准1：初始化控件并导入数据
这个测试构建了一个包含测试用Grid的用户控件，将其插入可视化树并加载数据。有个小插曲：通过代码创建的Xceed DataGridControl无法正常运行，所以最终采用了XAML方式来定义。

基准2：将数据重新载入现有控件
操作很简单：将DataGrid的ItemsSource设为null，清除现有数据及自动生成的列，再重新赋值为一个新的ListCollectionView实例。流程统一，所有控件一致。

基准3：单列排序
为了降低测试中的自定义代码量，我们主要借助ICollectionView接口实现排序。这是常规需求，理论上每个表格控件都应该原生支持。不过，Syncfusion的SfDataGrid本身没有内置排序功能，得手动操作它的SortDescriptions属性。测试Infragistics的XamDataGrid时也有个意外发现：它虽然支持ICollectionView排序，但在大数量下性能明显变差，于是我们改为访问FieldLayout的SortedFields属性来完成操作。

基准4与5：滚动百行并遍历全表单
我们很想模拟真实用户交互，但一直没找到完美方案。通过操作可视化树中的滚动条会影响性能，所以最终选择用让特定行进入可视区域的方式。幸运的是，目前主流的表格控件都提供类似ScrollIntoView的功能，稳定且高效。

测试结果

启动加载耗时
为了剔除JIT编译和XAML解析的开销，基准测试都从每个控件独立运行开始，方式与基准1基本一致。第一次启动的表现与后续运行会有差异，这也如实记录——对于WPF应用来说，这个启动时间确实是个关键指标。之后的多次测试显示，不论数据规模如何变化，系统稳定后的性能表现都高度一致。

固定列宽基准
分别以1,000、10,000、100,000项数据为源，结果如下：

自适应列宽基准
固定列宽之后，必须考察自动列宽模式，这才是真正的考验。但只有四款控件支持实时自动调整列宽：MS DataGrid和Telerik RadGridView采用默认的SizeToHeader模式；C1DataGrid启用默认的AutoStar；Infragistics XamDataGrid使用FieldLength.InitialAuto。我们在各自的最佳配置下跑了一遍，力求客观评估。

为什么其他控件没参与？C1FlexGrid、DevExpress的GridControl和Xceed的DataGridControl都没有提供即时列宽计算功能。这不算技术缺陷，更像是设计取舍——为了提升整体运行效率，开发者主动放弃了这一特性。虽然这些控件也提供了可调用的方法，但执行时机需要开发者自己把握，这在实际测试中带来了很大不确定性，无法客观反映性能，所以排除。

而Syncfusion的SfDataGrid，连类似的自动列宽计算能力都没有。大数量下，它的可用选项速度明显变慢，同样排除。

测试了包含1,000、10,000、100,000条数据的数据源，结果如图：

若干前提

平心而论，现在的WPF Grid控件在可视化性能和大数据量处理上，早已不是早年间人们印象中那个需要小心翼翼维护的‘老古董’了。如果你正在为应用程序选型，这些测试结果可以作为有力的参考依据。

当然，性能不是唯一的衡量标准。我们并没有测试分组、过滤、列数据可视化等用户场景。你可能因为易用性、XAML定制能力或内置功能的丰富程度，而更倾向于另一款产品。

在设定这些标准时，查阅了大量控件对比资料，发现所有WPF Grid大致可归为两类：一类是性能驱动的表格，自动列宽计算干脆不做；另一类则注重易用性和XAML的高效应用。这个分类令人印象深刻。

最后，可以留意到的是，我们2016 v2版的C1DataGrid性能提升显著，比此前版本快了超过35%。毕竟，对自己的产品做个总结，也是理所当然的事。