ObservableCollection 数据绑定性能 [英] ObservableCollection Databinding performance

问题描述

我想知道为什么根据这个文章和observable集合的绑定速度比 WPF 中的 List<> 集合快得多(20 毫秒对 1685 毫秒，快 800 倍).我查看了 ObservableCollection 的内部结构，它使用一个 List 作为它的存储集合对象(我使用了反射器并在构造函数中看到了这一点)

I would like to know why according to this article and observable collection binds significantly faster(20 ms vs 1685ms, that's 800X faster) than a List<> collection in WPF. I looked at the internals of ObservableCollection and it uses a List as it's storage collection object(I used reflector and saw this in the constructor)

public Collection()
{
    this.items = new List<T>();
}

这里发生了什么?

推荐答案

那篇文章中的比较不是两个简单的绑定操作之间的比较，这些度量指的是您向 WPF 中添加单个项目的场景 已经绑定到 List 或 ObservableCollection 的 ListBox.

The comparison in that article isn't between two simple binding operations, those measurements refer to a scenario in which you add a single item to a WPF ListBox that is already bound to either a List<T> or an ObservableCollection<T>.

正如作者所说:

...CLR List 对象不会自动引发集合更改事件.为了获取 ListBox 以获取更改，您将不得不重新创建您的员工名单并重新附加它到 ItemsSource 属性列表框.虽然此解决方案有效，但它引入了巨大的性能影响.每次重新分配 ItemsSourceListBox 到一个新对象，ListBox 首先扔掉它之前的项并重新生成其整个列表.

...the CLR List<T> object does not automatically raise a collection changed event. In order to get the ListBox to pick up the changes, you would have to recreate your list of employees and re-attach it to the ItemsSource property of the ListBox. While this solution works, it introduces a huge performance impact. Each time you reassign the ItemsSource of ListBox to a new object, the ListBox first throws away its previous items and regenerates its entire list.

这解释了性能差异.尽管 ObservableCollection 由 List 支持，但它实现了 INotifyCollectionChanged 接口，这使得所有额外的处理变得不必要.

This explains the performance difference. Even though ObservableCollection<T> is backed by a List<T>, it implements the INotifyCollectionChanged interface, which renders all that extra processing unnecessary.

这篇关于ObservableCollection 数据绑定性能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！