核心数据性能：NSPredicate 比较对象答案

【问题标题】：Core Data Performance: NSPredicate comparing objects核心数据性能：NSPredicate 比较对象
【发布时间】：2012-01-26 11:55:12
【问题描述】：

如果我的Author NSManagedObject 模型具有authorID 属性（由服务器确定），如果NSPredicate 按authorID 而不是完整的Author 对象过滤，NSFetchRequest 的性能会更好吗?假设我正在通过某个author 获取所有Book NSManagedObjects。哪个predicateFormat更好？

[NSPredicate predicateWithFormat:@"author = %@", anAuthor]

或

[NSPredicate predicateWithFormat:@"author.authorID = %@", anAuthor.authorID]

对此进行分析的最佳方式是什么？我使用OCUnit (SenTestingKit) 进行核心数据测试。 iOS有类似Ruby's Benchmark module的东西吗？

【问题讨论】：

在执行提取时您手边有作者对象吗？如果您要使用 Author 对象，我假设您需要先获取它，然后对该作者的书籍执行第二次请求（两次访问数据库）。如果您已经拥有 id，则可以通过一个 fetch 请求获得所需的结果。
这不会解决您的问题，但您最好知道 Apple 文档指出您应该在编写谓词时使用 '==' 而不仅仅是 '='。

标签： performance core-data profile nspredicate nsfetchrequest

【解决方案1】：

使用-com.apple.CoreData.SQLDebug 1 的参数来运行您的应用程序可能是值得的，详细的here。

然后您可以查看 Core Data 在两种情况下是否执行相同的 SQL（假设您使用的是 SQLite 存储）。

【讨论】：

【解决方案2】：

第一个（仅使用Author）可能会更快，但只有测试才能确定。

如果您获取（例如Book）与Author 有关系的对象并且您使用谓词

[NSPredicate predicateWithFormat:@"author = %@", anAuthor]

SQLite 可以查看从Book 到Author 的合并表是否具有给定author 的正确主键。换句话说，谓词变成了对Author 实体主键的检查。不过，CoreData 仍然需要查询合并表。

如果你使用

[NSPredicate predicateWithFormat:@"author.authorID = %@", anAuthor.authorID]

然后 SQLite 必须将 join 合并表与实际的 Author 表匹配，然后匹配生成的 authorID 列。那将是更多的工作。如果authorID 没有被索引，它就会崩溃。

【讨论】：

我在调试类似谓词时遇到了这个问题；使用与第一个示例中相同的格式，我无法使基于对象的谓词起作用。直接在 sqlite 中检查数据确认它不起作用。我想了解更多信息，或了解为什么它可能不起作用
SQL 请求是什么样的？你在做什么检查？