优化批量删除和创建NSManagedObjects

当用户下载我的应用程序并'注册'时，我们用核心数据填充用户数据，这可能会潜在成千上万的对象。优化批量删除和创建NSManagedObjects

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

在批量创建和删除中常见的是这些过程花费了大量时间。

进行明显的优化和使用时间轮廓仪后，我到达的最大瓶颈似乎是这种模式的结论：

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

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

这似乎是服用65-70％的所有的CPU时间在创建和删除过程中。我试图尽量减少在创建时受到伤害的对象的数量，但是有一个我不能进一步降低的最小数量。

但是对于删除，看起来标记为被删除的对象必须被获取，无故障并且再次发生故障，因此didTurnIntoFault被调用以用于所有被删除的对象。我在didTurnIntoFault中执行了大部分对象清理，但令人惊讶的是，从默认的NSNotificationCenter中以观察者身份移除对象似乎是最重的操作（大幅度）。

任何想法为什么removeObserver：变得如此沉重？有关如何优化此更快注册/注销的想法？

来源

2014-02-08 Apoorv Khatreja

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

为什么你甚至需要数千个物体？保持多个商店和延迟加载。 – Wain

我不确定多个商店如何在创建和删除期间帮助我需要插入/删除所有对象。 –

NotificationCenter是一个强大的工具，带有一些成本。当你在没有接收/产生对象的情况下使用它时（object:nil在你的代码中），那么事情可能会横向并且开始变得昂贵。

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

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

如果这两个都不合适，那么需要更好地理解该通知的用途。

来源

2014-02-08 17:18:08

优化批量删除和创建NSManagedObjects

回答

相关问题