缓慢加载核心数据中的持久性存储协调器

Question

我一直在开发具有核心数据的Cocoa应用程序。最初一切似乎都很好，但是当我将数据添加到应用程序时，我发现初始数据窗口需要很长时间才能加载。为了解决这个问题，我转移到另一个没有数据的启动窗口，所以启动很快。然而，无论我做什么，我的第一次获取和我第一次尝试加载数据窗口（使用表视图）总是很慢。 （也就是说，如果我慢慢读取数据，然后询问数据窗口，那么第一次都会变慢。）然后，性能可以接受。

我追踪了我的应用程序，发现虽然我可以快速地完成程序，但无论如何，检索持久性店铺协调员的步骤非常慢......使用旋转的沙滩球可能会花费15到20秒。

我读过其他地方，我可能要进行非规范化的数据。我不认为这是足够的。早期的版本在实体之间“相互关联”要少得多，它在启动时仍然是一团糟。现在我正在查看可能拥有高达18,000个托管对象的实体。一些关系对于使数据正常工作至关重要。

我也看到了有关使用在后台单独的管理对象范围内的选择。问题在于，即使是这种背景环境也需要很长时间才能使用。如果用户试图运行搜索，他或她仍然会永久等待该上下文加载。当用户决定要在搜索字段中输入什么内容时，我可能会花几秒钟购买自己的产品，但我无法承受25秒的停顿时间。

我们注意到：一旦数据被导入到持久性存储，甚至搜索上是不相关的人（和只有1000个对象）仍需要年龄加载表。原因似乎是协调器检索本身很慢，而不是实际的获取或上下文。

任何人都可以点我就如何解决这个正确的方向？谢谢！

Answer 1

在你创建你的数据模型：

如果你存储大量的对象，例如照片，音频或视频，你必须非常小心你的模型设计 。

关键的一点要记住的是，当你把一个管理对象到上下文，你把所有的数据到内存。

如果大照片位于从驱动表视图的相同实体剪下的管理对象内，则性能将受到影响。即使您使用的是抓取的结果控制器，您仍然可以一次加载超过一打的高分辨率图像，这不会是瞬间的。

为了解决这个问题，属性，将举行大型物体应该被剥离到相关实体。通过这种方式，大对象可以保留在持久性存储中，并可以由故障代替，直到它们确实需要为止。

如果您需要在表格视图中显示照片，则应该使用自动生成的缩略图图像。

Read the whole article

Answer 2

你可能会走在前面的自己认为PSC是罪魁祸首。 CoreData在幕后有更多的东西比显而易见--PSC非常灵活，必须定向。
您指定的数据大小（18K）的实际方法是关注模块化您的提取请求模板的逻辑并针对特定大小的情况进行验证（请考虑小型中等大型XtraLarge等）。

对数据进行非规范化的建议没有考虑到使数据进入完全非规范化状态的开销，加上非规范化的（有时）非预期副作用是稀疏性（除非您有非常具体的模型） 。

由于您通常事先并不知道预先访问和修改了哪些数据，因此请在您的中心任务和任何子任务之间建立一对多关系。这将释放您的数据访问的一些限制。

您可以随时为最终用户提供选择他们想要处理大型数据集的方式的选项。