我正在测试WPF DataGrid，希望能够取代一些winforms控件，并且到目前为止对开发过程非常满意。性能似乎是我现在最关心的问题。我的开发工作站拥有运行Windows 7的市场上最好的CPU，有6台DDR3内存。我正在替换的窗口控件响应速度更快，这令人担忧。
我的测试是绑定到ObservableCollection的DataGrid的基本实现，它每秒更新一次。它还包括详细信息区域，可扩展以显示有关每行的更多信息。详细信息区域只是一个stackPanel，其中ItemsControl包装TextBlock（重复6次）
我的抱怨是，如果我尝试滚动此集合，它通常是滞后的，如果我尝试扩展每一行，大约15％的点击不会触发按钮点击事件（DataGridTmplateColumn＆gt; CellTemplate＆gt; DataTemplate＆gt; Button） 如果某些行细节被展开，滚动也会更加抖动（使用滚动条可以在向上/向下调整其自身大小）
有什么需要寻找的东西/优化/避免？
更新
以下是我发现有用的一些要点：
尽可能少地依赖动态布局。因为每个组件包含许多子组件并且在动态布局世界中，所有组件都必须调用可以是cpu密集型的测量和布局方法。因此，使用固定宽度
安装WPF Performance Suite并与您的应用呈现方式保持联系。真棒的应用程序
正如Andrew所指出的，ListView是一个很好的选择，因为当你不需要高级DataGrid功能时，例如更新数据，或者可能是Details View（我仍然希望重现）
SuspendableObservableCollection也非常适合在非常短的时间内添加多件商品（即0.01秒内的100件商品等）
经过大量测试后，我发现BindingList比ObservableCollection快得多。我发布了由BindingList和Observable集合处理的相同负载的性能分析器快照here，前者占用不到一半的CPU时间。 （请记住，这不仅仅是收集性能，而是与ListView配对时）
我的搜索仍在继续，因为某些内容似乎在我的应用中泄漏内存，并在几小时后将其降低到停止状态。
答案 0 :(得分：2)
DataGrid性能问题的一般提示：我在使用DataGrid时遇到问题，在窗口调整大小，列排序等等之后刷新了几秒钟，并锁定了窗口UI（1000行） ，5列）。
使用WPF大小计算得出问题（bug？）。我在RowDefinition Height =“Auto”的网格中得到它，这导致渲染系统尝试通过测量每个列和行的大小来尝试重新计算DataGrid的大小，可能是通过填充整个网格（据我所知）。它应该以某种方式智能地处理它，但在这种情况下它不是。
快速检查以确定这是否是一个相关问题是在测试期间将DataGrid的高度和宽度属性设置为固定大小，然后再次尝试运行。如果您的性能已恢复，则可以在以下选项中进行永久性修复：
答案 1 :(得分：1)
你的意思是来自WPF Toolkit的DataGrid？如果是，在我看来它很慢，所以我最终使用ListView和GridView。
答案 2 :(得分：1)
更一般的提示：
对于滚动，我们尝试使用Deferred Scrolling。
要提高过滤性能，您可以考虑自己过滤绑定的集合。
对于具有大量列的网格，也应用ColumnVirtualization。这往往会对水平滚动产生一些不利影响，但您可以测试您的场景并应用改进。对我们来说它确实很有效。它帮助我们完成了大网格的刷新，重新加载，渲染场景。
应用样式也会影响性能。