什么是资源密集型:绑定,KVO或通知

Question

而不是试图运行一堆测试.有人知道资源密集程度较低吗？

绑定,KVO或通知？有人测试过吗？

Answer 1

在OS X上,它通常并不重要.它们都很轻巧.Apple本身依赖它,因此实现得到了高度优化.我会编写代码,使其尽可能可读,并且只在必要时优化速度/资源消耗.

另一点是Apple经常改变OS版本的实现.因此,各种特定技术的相对成本(速度,资源消耗等)经常改变.在网上可以找到什么可以经常过时.Apple本身强调永远不要假设哪个更快更轻,而是使用分析器(仪器等)来自己测量瓶颈.

Answer 2

Chuck的答案对于KVO的通知而言是完全正确的,但是我想扩展他所提到的"Bindings是KVO + KVC + ......"部分,因为这是屁股真正的痛苦所在.关键值编码似乎是这里更重要的考虑因素,因为没有它就不能使用Bindings.如果你担心性能有充分的理由,你应该注意KVC的大量使用成本会引起.

我会说任何因单个动作而需要进行大量查询的情况(例如:向几千个对象询问每个多个键路径的结果)将表明您可能想要避免KVC(和Bindings by延期).特别是使用长键路径(-valueForKeyPath:vs. -valueForKey :).

我自己也很努力地反对这一点,现在正努力消除我的架构的这一部分.当您按下按钮时(即使使用NSOperation/Queue)要求16,000个对象获得六个长键路径的结果时,键值编码的相对微小的成本会严重累加.使用KVC和老式[[对象消息]消息...]调用之间的区别可能意味着在大型作业上几秒钟到一两分钟之间的差异.对我来说,直接调用访问器的相同查询(如[参数名称]或[[参数变量]名称])大约表示速度增加了500%.当然,我的是一个非常复杂的数据模型,具有大量典型文档的数据.

另一方面,如果您的应用程序的许多单个操作影响/查询一个或少数几个对象,并且主要是面向键值观察(即更改姓氏并在一些视图中同时更新),其简单性可以类似魔术.

总结:如果你的应用程序查询/更新大量数据,你可能会做的更好,以避免KVC和绑定,因为查询/更新部分KVC,不会因为志愿.