基本上，我想知道它在這裏的效率如何。INotifyCollectionChanged - 它多久發一次（以及它們如何使它如此高效/快速）？
示例代碼：
void GetItems()
{
foreach (var item in items)
myObservableCollection.Add(item);
}
這會不會關火CollectionChanged事件，每次導致UI有刷新每次？還是這樣做，直到GetItems函數完成？
基本上，WPF似乎處理得很好，我想知道他們是怎麼做到的。
事件將隨着每一個變化而發生。
GUI不必每次都反應和刷新，它可以推遲。
我知道WinForms會優化這個，我認爲WPF有一個類似的方法。
Optimizing Performance: Data Binding提供了一些有關如何解決數據綁定的背景知識，包括不同項目源的性能影響。看看Binding to an ItemsSource部分。
考慮中，你必須持有 要在ListBox中顯示員工列表的CLR List對象的場景。要在這兩個對象之間創建一個 對應關係，您可以將您的員工 列表綁定到ListBox的ItemsSource屬性。但是，假設您 有一名新員工加入您的小組。您可能會認爲按照 的順序將此新用戶插入您綁定的ListBox值中，您只需將此人添加到您的員工列表中，並希望數據綁定引擎自動識別此更改爲 。
該假設將被證明是錯誤的;實際上，更改不會自動在ListBox中反映出 。這是因爲CLR 列表對象不會自動引發集合更改爲 事件。爲了讓列表框獲得更改，您必須重新創建您的員工列表並將其重新附加到列表框的ItemsSource屬性 。儘管此解決方案有效，但它會帶來巨大的性能影響。每次將ListBox的ItemsSource重新分配給一個新對象時，ListBox首先將其前一項丟棄 並重新生成其整個列表。如果您的ListBox映射到複雜的DataTemplate，則影響會被放大。
解決此問題的一個非常有效的方法是讓您的員工 列出ObservableCollection。 ObservableCollection對象 引發數據綁定引擎可以接收的更改通知。該事件添加或刪除ItemsControl 中的項目，而無需重新生成整個列表。
更新時間爲1個項目（MS）
- 到CLR列表對象= 1656毫秒
- 要一個ObservableCollection = 20毫秒
WPF從未直接結合到收集。如果將集合指定爲綁定源，則WPF實際上綁定到集合的default view。
集合視圖是在結合源集合 ，允許你基於 排序，過濾，和組查詢導航和顯示源集合，頂部上的層，而無需改變它的 底層源收集本身。集合視圖還維護 指向集合中當前項目的指針。如果源 集合實現INotifyCollectionChanged接口，則CollectionChanged事件引發的更改將傳播到 視圖。
如果你想看到的UI請求多久新鮮結果公開爲公共財產，並把調試行的公共屬性myObservableCollection的get（評估員）。
因此，基本上運行和更新GUI的代碼正在執行性能優化。 – michael
是的。 WinForms只是在更改屬性時使控件失效，並且只在事件隊列爲空時重新繪製它。 –
在WPF中，每個'CollectionChanged'事件都將一個框架推送到主線程的'Dispatcher'隊列中;當調度員接近它時，它將從源值「調用」綁定更新。因此，如果有很多更改通知要處理，用戶從不會注意到任何放緩或無響應;它只是意味着一個特定的控件可能會顯示過時的數據，直到它被處理。 – Aphex