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

我一直在开发一款具有核心数据的Cocoa应用程序。起初，一切似乎都很好，但当我向应用程序添加数据时，我发现初始数据窗口的加载耗时很长。为了解决这个问题，我转到了另一个没有数据的启动窗口，所以启动很快。然而，无论我做什么，我的第一次获取和第一次尝试加载数据窗口（带有表视图）总是很慢。（也就是说，如果我缓慢地获取数据，然后请求数据窗口，两者在第一次都会很慢。）之后，性能是可以接受的

我通过我的应用程序进行了跟踪，发现尽管我可以快速完成程序，但无论如何，检索持久存储协调器的步骤都非常慢。。。一个旋转的沙滩球可能需要15-20秒

我在其他地方读到过，我可能想对数据进行非规范化。我认为这还不够。早期的版本在实体之间的“互联性”要小得多，在启动时仍然是一个瓶颈。现在我看的是可能有18000个托管对象的实体。有些关系对于数据正常工作至关重要

我还阅读了关于在后台使用单独的托管对象上下文的选项。这样做的问题是，即使这个背景上下文也需要很长时间才能使用。如果用户试图运行搜索，他或她仍将永远等待加载该上下文。当用户决定在搜索栏中键入什么内容时，我可能会给自己买几秒钟，但我不能拖延25秒钟

我注意到，一旦将数据导入到持久性存储中，即使是在与其他表无关（并且只有1000个对象）的表上进行搜索，也需要很长时间才能加载。原因似乎是协调器检索本身速度慢，而不是实际的获取或上下文

---

有人能告诉我如何解决这个问题的正确方向吗？谢谢

在创建数据模型之前：

如果要存储大型对象，如照片、音频或视频，则需要非常小心模型设计

要记住的关键点是，当您将托管对象放入上下文时，您将其所有数据放入内存中

如果大型照片位于从驱动表视图的同一实体剪切的托管对象中，则性能将受到影响。即使您使用的是“抓取结果”控制器，也可能一次加载十几张高分辨率图像，这不是即时的

为了解决这个问题，应该将包含大型对象的属性拆分为相关实体。这样，大型对象可以保留在持久性存储中，并可以用故障来表示，直到真正需要它们为止

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

---

你可能认为PSC才是罪魁祸首。 CoreData的幕后活动比显而易见的要多——PSC非常灵活，必须加以指导。
对于您指定的数据大小（18K），一种现实的方法是将重点放在对获取请求模板的逻辑进行模块化，并针对特定大小的情况进行验证（比如小型、中型、大型XtraLarge等）

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

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

---

您可以随时为最终用户提供选择如何处理较大数据集的选项。

18000不是很大。。。它实际上非常小，因为核心数据。。。不幸的是，您没有提供足够的信息。加载PSC可能涉及很多事情，比如迁移等。此外，获取与PSC的初始创建无关，因此我不明白为什么要将PSC和获取混合在一起。也许如果您展示一些代码，以及代码的哪些部分会消失那么长时间，这会有所帮助。否则，你得到的任何答案都将是纯粹的猜测。同意乔迪的观点。你必须问一个更具体的问题。如果你的论文是正确的，并且是PSC，请修改问题以说明你是如何创建它的。打开存储将同步访问文件系统。如果可以，请不要从主队列中打开存储。我创建的存储是默认存储。最初我使用XML存储类型，但速度太慢了。使用SQL store类型有帮助，但还不够。虽然我的应用程序只有50条记录，加载时间长达7秒，但同样的问题仍然没有解决。