AFIncrementalStore 的性能问题答案

【问题标题】：Performance issues with AFIncrementalStoreAFIncrementalStore 的性能问题
【发布时间】：2013-08-14 13:44:21
【问题描述】：

我正在试验 AFIncrementalStore，这很棒，但我注意到我遇到了一些性能问题。

具体来说，我正在使用它从 facebook graph api 中删除一堆 facebook 朋友信息，并且我看到一些非常慢的时钟时间用于保存操作。对于上下文，我正在加载大约 900 条记录。 Instruments 告诉我问题是这样的：

 NSManagedObjectID *backingObjectID = [self objectIDForBackingObjectForEntity:entity withResourceIdentifier:resourceIdentifier];

它又调用它

[backingContext performBlockAndWait:^{
        backingObjectID = [[backingContext executeFetchRequest:fetchRequest error:&error] lastObject];
    }];

有没有人有过使用 AFIncremental 存储更大数据集的经验？

我不太明白的其他一些事情是为什么所有这些操作都发生在主线程上，而所有这些操作都使用来自 PrivateQueueConcurrencyType 的上下文中的performBlockAndWait 操作启动。非常感谢任何帮助！

【问题讨论】：

我承认收集有关核心数据的特定主题的文档很痛苦，因为官方文档中没有任何内容。那是苹果的错。但是，您可以在 SO 上找到问题的答案，例如：NSManagedObjectContext performBlockAndWait: doesn't execute on background thread?。只是对链接中答案的一个澄清：该块实际上将在私有队列上执行，但调用线程将被阻塞直到完成。

【解决方案1】：

只是部分答案：

performBlockAndWait: 将执行私有队列上的块，但调用线程将“显示等待”直到块完成。（注意“出现等待”，解释如下）。

队列是同步访问共享资源的底层机制。这确保可以同时访问共享资源。

现在，GCD 可以在选择用于驱动队列的线程方面进行优化：如果您调度同步 GCD 可以选择使用驱动私有的当前线程专用队列。

注意：在特定队列中排队的块可以在任何线程上执行。尽管如此，“执行上下文”是队列——它决定了同步。

因此，换句话说，performBlockAndWait: 将显示为好像将被同步调用。如果块将在同一个线程上执行，则该线程不会阻塞。它只是在执行块时切换到私有队列（从而保证共享访问）。这是有道理的，因为消息的名称表明：“..AndWait”。

【讨论】：