单独的可观察集合与筛选后的可观察集合性能对比

6

对于大型集合绑定,例如:

需求 - 电子交易应用程序:

价格汇总表 - 显示不同证券的行情/交易。例如。

主视图 - 显示所有报价。

国家视图 - 显示属于特定国家的证券的报价/交易。例如英国/法国等。

目前 - 我们为每个视图拥有可观察集合,并且当价格从服务器到达时,我们根据过滤器向每个可观察集合发送一份副本,即一个发送到主视图,根据国家发送到国家视图,例如。

问题:过滤后的可观察集合是否优于此模型,即使CollectionViewSource在添加/删除价格时需要进行刷新。刷新CollectionViewSource是否会增加性能损失。

上面的示例仅供参考,可能有多达20个不同的视图,以及多达20-50K的价格,每个价格都有非常大的日内价格深度,应用程序在GUI性能方面需求高。

我打算使用轻量级Tableview替换当前的Datagrid,想知道单个主可观察集合是否也有帮助。

感谢您的回复。


你预计用户在任何单一时刻会打开多少视图?如果你有一个主要的可观察集合,并且你从集合中添加/删除一个项目,那么所有引用该集合的元素都将更新其绑定元素。假设你有20个视图打开,那么你需要处理20个UI更新。 - Mike Eason
假设-所有20个视图。Blotter是一个控件,每个视图都是选项卡。所有对视图的引用都会更新绑定元素,这很好-但基础的“过滤”CollectionView将有过滤记录,对吗?例如,主要Observable Collection有5条记录(英国,德国,美国,西班牙,意大利)-主视图显示全部5条,英国显示1条,依此类推。添加新元素(英国),主要Observable Collection将有6条记录,英国将有2条记录,其他仍为空等等。目前使用每个视图都有自己的ObS Col来实现。消息层根据国家和视图类型路由到适当的视图,仅作为示例。 - Vinay Dwivedi
你是否尝试过使用 ICollectionView 显示单个可观察集合的筛选表示形式?启用 UI 控件的虚拟化后,即使有大量数据,性能也应该良好。 - kenjara
我在UserView、GroupView(订单更多)、AccessibleView(甚至比GroupView还多)、CompletedView和CustomFilterView中有5个选项卡,平均每个选项卡有5000多个订单。使用FilterCollection方法没有性能问题。我相信你正在使用DevExpress或Infraguistic,它们默认已经开启了虚拟化功能。无论如何,在后台线程更新FilteredCollection时,有两种Grid更新方式,并且可以使用Begin/End update批量更新。 - cscmh99
2
在一个类似的项目中,我创建了自己的CollectionView,并支持数据虚拟化的底层列表。我在虚拟数据集中实现了一种分页机制,并将过滤表达式传输到服务器端。结合DataGrid中的UI虚拟化,CollectionView通过索引提供数据。使用WCF服务,可在几毫秒内加载可见行。有了快速的服务器,视图甚至不会闪烁。用户可以在不受UI限制的情况下滚动整个列表。如果需要,我可以在答案中分享代码。 - Daniel Leiszen
1个回答

0

CollectionViewSource 上的刷新可能会对性能产生非常不利的影响,因为它会导致视图中的项和项容器重新生成(请参见下一句中的链接)。这就是为什么在 WPF 中有 可编辑集合 的整个原因。我曾经为一个产品实现了大型可修改集合,当我使用 IEditableCollectionView 时,我从未遇到过性能问题,尽管这并不意味着它对您的应用程序来说速度足够快。

我的猜测是,如果您正在使用 IEditableCollectionView,那么无论您将集合拆分还是保持所有集合在一个巨大的集合中并应用不同的筛选器,都不会有太大影响。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接