新的 ObservableCollection 与在循环中添加项目
就速度和生成的通知数量而言，这段代码是否：
ObservableCollection<Foo> foo = new ObservableCollection<Foo>(bar);
this.SomeProperty = foo;
相同：
this.SomeProperty = new ObservableCollection<Foo>();
foreach (var v in bar)
{
this.SomeProperty.Add(v);
}
如果它们相同，是否可以以某种方式关闭生成的通知？
目标： 我正在尝试加快 Telerik RadChart 在 silverlight 中的显示速度。即使设置了包含 ObservableCollection 的属性，似乎也需要一段时间才能显示（并冻结浏览器应用程序）。绘制图表后，一切正常。
In terms of speed and the amount of notifications generated, is this code:
ObservableCollection<Foo> foo = new ObservableCollection<Foo>(bar);
this.SomeProperty = foo;
the same as:
this.SomeProperty = new ObservableCollection<Foo>();
foreach (var v in bar)
{
this.SomeProperty.Add(v);
}
If they are the same, is it possible to somehow turn off the notifications generated?
Objective:
I'm trying to speed up the display of Telerik RadChart in silverlight. It seems to take a while to display (and freezes the in browser app) even after the property containing ObservableCollection is set. Once the chart is drawn everything works correctly.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
分析它或测试它！根据文档，
添加、删除项目时，会发生 PropertyChanged 事件
更改、移动或刷新整个列表。因此你可以
编写一些仅订阅此事件的测试代码，看看会发生什么
发生。
快速执行且线程安全的可观察集合 - 如果是由于持续不断的 OnChanged 事件，请考虑仅在批量更新后触发 - 有人已经为您完成了这项工作
http://www.telerik.com/help/silverlight/ radchart-performance-tips-and-tricks.html
专门处理您在页面一半处描述的场景。他们的结论与 2 相同 - 事实上，代码看起来非常相似:-)
如果冻结发生在绑定实际发生之前，那么我会确保延迟实际上不是基于渲染或由于其他原因活动（例如加载集合所花费的时间）。再说一次，分析是你的朋友。
Profile it or Test it! According to the docs, the
PropertyChanged event occcurs when an item is added, removed,
changed, moved, or the entire list is refreshed. You can therefore
write some test code that just subscribes to this event and see what
happens.
Fast performing and thread safe observable collection - if it is due to a constant barrage of OnChanged events, consider only firing after a bulk update – someone has done this work for you already
http://www.telerik.com/help/silverlight/radchart-performance-tips-and-tricks.html
deals specifically with the scenario you describe about half way down the page. Their conclusion is the same as 2 - in fact, the code looks very similar :-)
If the freeze is occuring before the binding actually takes place, then I'd make sure that the delay isn't actually rendering based or because of another actvity (like the time taken to load the collection). Again, profiling is your friend.