gpt4 book ai didi

c# - WPF DataGrid 性能问题

转载 作者:可可西里 更新时间:2023-11-01 08:12:25 32 4
gpt4 key购买 nike

我正在测试 WPF DataGrid,希望能取代一些 winforms 控件,到目前为止,我对开发过程非常满意。性能似乎是我现在最关心的问题。我的开发工作站拥有市场上运行 Windows 7 的最佳 CPU,以及 6 GB 的 DDR3 内存。我正在替换的 Windows 控件的响应速度要快得多,这令人担忧。

我的测试是绑定(bind)到每秒更新一次的 ObservableCollection 的 DataGrid 的基本实现。它还包括详细信息区域,该区域可扩展以显示有关每一行的更多信息。详细信息区域只是一个带有 ItemsControl 包装 TextBlock(重复 6 次)的堆栈面板

我的提示是,如果我尝试滚动此集合,它通常会因滞后而不稳定,如果我尝试在它们进入时展开每一行,大约 15% 的点击不会触发按钮点击事件(DataGridTmplateColumn > CellTemplate > 数据模板 > 按钮)如果某些行的详细信息被展开(滚动条在向上/向下时自动调整大小),滚动也会更加紧张

需要寻找/优化/避免哪些事情?

更新

以下是目前我发现有帮助的一些要点:

  • 尽可能少地依赖动态布局。由于每个组件都包含许多子组件,并且在动态布局世界中,它们都必须调用 Measure 和 Layout 方法,这可能是 CPU 密集型的。所以不要使用自动列宽(或未指定宽度),而是使用固定宽度

  • 安装 WPF Performance Suite并了解您的应用程序是如何呈现的。非常棒的应用

  • 正如 Andrew 指出的那样,ListView 是一个很好的替代方案,适用于当您不需要高级 DataGrid 功能时,例如更新数据或可能的详细信息 View (我仍然希望重现)

  • SuspendableObservableCollection非常适合在很短的时间内添加多个项目(即 0.01 秒内添加 100 个项目等)

  • 经过大量测试,我发现 BindingList 比 ObservableCollection 快得多。我发布了性能分析器快照 here BindingList 与 Observable 集合处理的相同负载,前者占用的 CPU 时间不到一半。 (请记住,这不仅仅是集合性能,而是与 ListView 配对时的性能)

我的搜索仍在继续,因为我的应用程序似乎正在泄漏内存,并在几个小时后减慢速度直至停止。

最佳答案

DataGrid 性能问题的一般提示:我遇到了一个 DataGrid 问题,它在调整窗口大小、列排序等后需要几秒钟的时间来刷新,并在这样做时锁定了窗口 UI(1000 行) , 5 列)。

归结为 WPF 大小计算的问题(错误?)。我把它放在一个 RowDefinition Height="Auto"的网格中,这导致渲染系统在运行时通过测量每一列和每一行的大小来尝试重新计算 DataGrid 的大小,大概是通过填充整个网格(据我了解)。它应该以某种方式智能地处理这个问题,但在这种情况下却没有。

要查看这是否是相关问题的快速检查是在测试期间将 DataGrid 的 Height 和 Width 属性设置为固定大小,然后再次尝试运行。如果您的性能得到恢复,永久性修复可能包括以下选项:

  • 将包含元素的大小更改为相对大小 (*) 或固定值
  • 将DataGrid的MaxHeight和MaxWidth设置为较大的固定值超出正常使用范围
  • 尝试另一种具有不同大小调整策略的容器类型(Grid、DockPanel 等)

关于c# - WPF DataGrid 性能问题,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/3022921/

32 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com