核心数据 - 原始设置器/获取器更快吗？啥时候不使用？

Posted 2023-03-04

【中文标题】核心数据 - 原始设置器/获取器更快吗？啥时候不使用？

【英文标题】：Core Data - Are primitive setters / getters faster? When not to use?核心数据 - 原始设置器/获取器更快吗？什么时候不使用？

【发布时间】：2012-12-21 02:16:24

【问题描述】：

来自 Apple 的核心数据编程指南：

Core Data 动态生成高效的公共和原始 get 和 设置属性访问器方法和关系访问器方法 托管对象类。

...

原始访问器方法类似于“普通”或公共键值 编码兼容的访问器方法，除了 Core Data 将它们用作 访问数据的最基本的数据方法，因此它们不 发出键值访问或观察通知。换一种方式， 他们是primitiveValueForKey：和setPrimitiveValue：forKey：什么 公共访问器方法是 valueForKey: 和 setValue:forKey:。

然后我希望原始访问器方法比公共访问器具有更好的性能，因为它们不会触发 KVO 通知。有没有办法用 Time Profiler 有效地测试这个理论？ （当然，这不可能像将两个调用放在它们自己的 for 循环中那样简单，这些循环会迭代无数次并比较结果......）

很明显，原始访问器不能被托管对象子类之外的对象或函数调用，但是什么时候不应该在类中使用它们？

【参考方案1】：

edelaney05，

如您所知，Core Data 依赖于 Objective-C 的 KVC/KVO 特性。是的，您是正确的，通过访问器的路径长度稍长。它呢？ Core Data 的性能主要取决于 I/O 子系统的性能。

IOW，调整获取请求比避免访问器开销重要得多。你能做到你提议的吗？是的。你应该？不，IMO，您应该专注于如何有效地将数据放入 MOC，然后使用谓词和其他过滤技术对其进行优化。学习如何在提取后使用各种关键路径运算符和谓词语言对于编写高性能的 CD 代码非常重要。只有在 Instruments 可以记录您在访问器中花费了大量时间之后，我才会考虑您避免使用它们的策略。

在回答您的具体问题时，您通常应该将原始访问器的使用限制在您重新实现公共访问器的范围内。坚持使用所有代码的访问器将成为您的标准模式。这为您提供了将任意行为与任何属性相关联的长期工程优势。最后，如果您可以使用各种密钥路径和集合运算符，那么 CD 团队已经优化了这些访问模式。它们的性能非常好。

安德鲁

【讨论】：

根据您的回答，这个问题似乎与“在 NSObject 子类中我不应该直接访问实例变量而不是使用它们的 get/set 方法，因为它更快吗？ "我的收获是在其他地方有更大、更容易和更智能的性能提升——当我输入问题时，我并没有想到这个想法 ;-)

edelaney05，如果我冒犯了你，我深表歉意。也就是说，我的观点是站得住脚的，对 ivars 也是如此。仅仅因为您可以访问它们并不意味着这样做是一种好习惯。这就是为什么 Objective-C 不再要求你声明它们的部分原因。他们巧妙地鼓励你忽略它们。安德鲁

我一点也不生气！关于 NSObject 子类的直接 ivar 访问，我完全同意你的看法，只是没有考虑与原语和 NSManagedObject 的并行性。