优化批量删除和创建 NSManagedObjects

Posted 2023-03-12

【中文标题】优化批量删除和创建 NSManagedObjects

【英文标题】：Optimizing bulk deletion and creation of NSManagedObjects

【发布时间】：2014-02-08 07:45:08

【问题描述】：

当用户下载我的应用并“注册”时，我们会使用用户数据填充 Core Data，这可能会遇到数千个对象。

我们还为用户提供了“注销”选项，此时我们会批量删除这些对象。 （我们不会删除底层的 sqlite 存储，因为其中的一些数据不是用户特定的，我们希望保留这些数据。

批量创建和删除的共同点是这些过程需要大量时间。

在进行了明显的优化并使用 Time Profiler 工具后，我得出的结论是，最大的瓶颈似乎是这种模式：

- (void)awakeFromFetch 
    [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(someSelector:) name:someNotification object:nil];


- (void)didTurnIntoFault 
    [[NSNotificationCenter defaultCenter] removeObserver:self];

这似乎占用了创建和删除期间所有 CPU 时间的 65-70%。我已尝试将创建时无故障的对象数量降至最低，但我无法进一步降低最小数量。

但是对于删除，似乎必须提取标记为删除的对象，无故障，然后再次出错，因此为所有已删除的对象调用didTurnIntoFault。我在didTurnIntoFault 中完成了大部分对象清理工作，但令人惊讶的是，从默认的 NSNotificationCenter 中删除作为观察者的对象似乎是最繁重的操作（相差很大）。

任何想法为什么 removeObserver: 变得如此沉重？有关如何优化此功能以加快注册/注销的任何想法？

【问题讨论】：

为什么不在用户注销时创建一个新商店。保留一个包含种子数据的新存储，并在用户注销时替换存储，而不是删除对象。或者使用两个存储，一个存储可丢弃的用户数据，另一个存储您要保留的数据，然后将用户数据替换为空的。

为什么你甚至需要数千个对象？维护多个存储和延迟加载。

我不确定多个商店在这里会有什么帮助，因为在创建和删除期间我需要插入/删除所有对象。

【参考方案1】：

NotificationCenter 是一个功能强大的工具，但需要支付一定的费用。当您在没有接收/生成对象的情况下使用它（代码中的object:nil）时，事情可能会横向发展并且事情开始变得昂贵。

所以我的第一个建议是通过添加一个对象来探索缩小通知的范围。希望有一个对象会抛出您收到的通知吗？如果是这样，你能以某种方式传递它吗？

第二个想法是将通知完全移出NSManagedObject。这将导致您做更多的工作，所以这是我的第二个建议，即使我更推荐它。考虑让控制器监听通知，引用NSManagedObjectContext，然后可以做相应的工作。

如果这些都不合适，则需要更好地了解该通知的用途。