ComponentOneWPF平台Grid控件性能比较
本文将从环境、测试应用、基准、测试结果等几个方面对
ComponentOneWPF平台下的Grid控件性能进行比较。
环境
这个基准创建于2016年6月，使用了下面Grid控件。（我们使
用的最新试用版）
?System.Windows.Control下的DataGrid
(PresentationFramework.dll的一部分)
?C1FlexGrid4.4.0.20162.514(ComponentOneWPF版)
?C1DataGrid4.4.0.20162.514(ComponentOneWPF版)
?XamDataGridv16.1.16.1.20161.1000(WPFControls-Infragistics)
?GridControlv15.2.15.2.10.0(WPFControls|DevExpress)
?SfDataGrid14.1400.0.41(SyncfusionEssentialStudioWPF版)
?RadGridView2016.2.503.40(TelerikWPFControls|UIWPF版)
?DataGridControlv5.9.5.9.16204.15420(XceedDataGridforWPF)
这个基准运行于ENVY-23All-in-OneDesktop环境，拥有下面的配
置。
Inteli7quad-coreCPU@3.10GHz
8GBRAM
NVIDIAGeForceGT630Mdisplayadapter,FullHD(1920x1080)
resolution
Windows10Pro64-bitOS
所有的Grid控件设置为相同的尺寸和默认的外观。
测试应用
我们的基准应用程序允许选择和运行单独的测试或者允许
一个接一个运行所有的测试。您可以选择同一个测试运行的次数，
这样可以在结果中得到平均值。
我们这样做可以减少其他方面的影响，比如操作系统和其他
应用程序的交互。所有展示在这里的结果都会运行10次。下面
是应用程序窗口。
基准测试应用程序窗口
如果要分析一个指定的用例，运行一个单独的测试是非常方
便的。注意：您需要在不同的测试间比较，在测试运行时请不要改变
窗体的尺寸。实际的视图尺寸会影响性能，就像大屏幕会消耗更多时
间和虚拟控件等资源用来布局从而影响其他事件。
这个应用会将测试结果写进working文件夹下的Excel文件。如
果您需要一个更详细的日志文件，您可以在App.xmal.cs文件中去掉
输出到TraceListener的注释。
这里最有趣的地方就是，如何去测试异步UI更新时的复杂操作
的运行时间。在几次试验后，我们发现我们想到的就是最合适的方法，
用于去获取当GirderUI完成更新时的准确时刻。完整源代码已经附
加，您可以去尝试。我们将很高兴收到关于您认为我们可以在某些方
面可以提高的反馈。
我们这里不包含任何的控件的二进制版本。如果您想运行应用，
您需要下载我们的WPF版本的试用版和其他参与比较的控件的使用
版。它们都拥有30天的免费试用期，这将不是问题。
基准
我们选择ListCollectionView作为数据源并且用下面定义的业务
对象来填充它。
它提供了12个不同类型的列。
我们尝试为Grid设置相同的条件，对于某些控件，我们更改
了某些设置来达到这一要求。
?自动生成列
?固定列宽
?允许在底部新行位置添加新行
?隐藏分组和搜素面板
?可编辑的单元格
每一个基准要遵循下面的步骤
1.移除上一次测试所创建的所有UI。调用GC.Collect和
GC.WaitForPendingFinalizers方法，使垃圾回收不会影响下次测试；
2.初始化下次测试和Stopwatch计时器；
3.按照需要的次数执行测试；
4.测量总时间并计算平均结果；
5.记录结果。
下面解释关于指定基准的实现细节
基准1创建控件并加载数据。
这个基准创建了一个用户控件，包含一个用于测试的Grid。将
它插入到可视化树中并填充数据。这样唯一的麻烦就是用代码创建
的XceedDataGridControl并不能正常工作。因此您将看到附加的应用
使用XAML创建它。
基准2:重新加载数据到存在的控件
基准设置DataGrid的ItemsSource为null，用于清空数据和自动
生成的列。然后设置ItemsSource为一个新的ListCollectionView。在
代码里，它就像下面这样（对于所有测试的控件都一样）
基准3:排列单列
我们尝试减少测试中自定义的代码，因此大多数情况下我们通过
IcollectionView接口来实现排列。
这是非常标准的，并且我们希望每个Grid都应内置支持。但
是Syncfusion的SfDataGrid并没有支持，所以我们需要通过
SfDataGrid.SortDescriptions属性来实现排序。
我们测试Infragistics的XamDataGrid时遇到了一个麻烦，他
可以使用ICollectionView排序，但是遇到大数据时变得很慢。当
我们想要得到所有控件的对比结果时，我们最终通过
FieldLayout.SortedFields来实现它。
基准４和５，滚动１００行，滚动整个表单。
我们认为这在测试中可以很好的模拟最终用户交互，但是没
有找到一个很好的办法。我们也许可以通过在可视化树中找到滚
动条并滚动。但是相关的代码也会影响性能，因此我们决定坚持
使特定行进入视图。所有的Grid都拥有ScrollIntoView或者相似
的办法来解决这件事。
测试结果
初始化加载时间
为了在所有的测试中避免计算JIT编译和XAML解析的次数，
我们从每个控件的一个单独的测试开始整个基准，这跟基准1是
几乎是相同的。当您在整个应用程序生命周期中第一次运行它，
您可以发现它跟接下来的运行不同。它被测量作为应用程序的
启动时间，这对WPF很关键，下面的测试显示了不论数据规格
几乎相同的结果。
初始化加载时间
固定宽度基准
下面是1,000，10,000，和100,000项作为数据源的结果
固定列宽下1000行数据的结果
固定列宽下10，000行数据的结果
固定列宽下100,000行数据的结果
自动列宽基准
在运行了固定列宽的测试之后，我们决定比较一下他们在自动列
宽时的表现。我们这项测试只针对四种具有即时自动列宽的Grid。我
想在每个Grid的最好情况下得到比较结果，因此我们选择MS的
DataGrid和Telerik的RadGridView的默认SizeToHeader选项，
C1DataGrid的默认AutoStar选项和Infragistics的XamDataGrid.的默
认FieldLength.InitialAuto选项。
为什么我们不对所有的控件都做这项测试呢？我们的C1FlexGrid
和DevExpress的GridControl以及Xceed的DataGridControl不支持即
时列宽计算。显然，这是设计者为了集中于控件的性能而做出的牺牲。
上面的所有控件都支持调用方法来自动计算列宽，但您需要在合适的
时间来调用合适的方法。这使它很难衡量整体性能，您也不能确定测
试结果是完全依赖于性能的。所以在我们的比较中不包含那些控件。
反之，Syncfusion的SfDataGrid控件没有类似MSDataGrid
和其他控件的自动列宽计算的选项，但是由于适用的选项在加载
大数据时速度变得很慢，它和其他控件是没法相比的。所以在这
个测试中我们也排出了它。
下面是我们分别测试包含1,000,10,000和100,000条数据的
数据源得到的结果。（与固定列宽用的是同样的基准）
自动宽度下1000行数据的结果。
自动宽度下10,000行数据的结果。
自动宽度下100,000行数据的结果。
一些条件
我们的结果与很久之前的关于WPFGrid性能的讨论不同，显然
现在的控件都具有可视化能力并且可以处理大量数据，如果您打算为
您的应用程序选择一个Grid，我们的结果是一个很好的参考。
另外没注意我们没有测试其他的场景，比如，分组、过滤和列数
据可视化。还有，性能并不代表全部，您有可能因为一些其它的原因
而喜欢上某个控件。比如易用性，XAML定制能力，内嵌支持的特性
数量等。
在制定这些基准的时候，我阅读了很多关于控件比较的信息，给
我很深的印象就是所有的WPFGrid可以分为下面两类：
?基于性能的Grid，不包含在自动列宽计算的测试中
?集中于易用性和XAML运用。
我们的WPF版本中包含以上两种控件，所以您可以选择最适应
您需要的一种。更多信息，参考附件中关于C1FlexGrid,C1DataGrid
和MSDataGrid详细功能的比较。
最终，在整个基准的比较的过程中，我情不自禁地要概括我
们自己的控件。所以我们又得到一个很有用的信息：2016v2版
本的C1DataGrid控件的速度优于之前的发布版本35%以上。
|
|
