核心数据中缓慢加载的持久存储协调器
我一直在用Core Data开发一个Cocoa应用程序。起初，一切似乎都很好，但当我向应用程序添加数据时，我发现初始数据窗口需要很长时间才能加载。为了解决这个问题，我转到了另一个没有数据的启动窗口，所以启动很快。然而，无论我做什么，我的第一次获取和第一次尝试加载数据窗口(带有表视图)总是很慢。(也就是说，如果我缓慢地获取，然后请求数据窗口，那么这两个窗口在第一次都会很慢。)在此之后，性能是可以接受的。
我跟踪了我的应用程序，发现虽然我可以快速地逐步通过程序，但无论如何，检索持久存储协调器的步骤都非常慢……旋转的沙滩球可能会经过15 - 20秒。
我在其他地方读到过，我可能想要对数据进行反规范化。我认为这还不够。较早的版本在实体之间的“互连”程度要低得多，而且在启动时仍然是一个弹头。现在，我正在研究那些可能拥有多达18,000个托管对象的实体。其中一些关系对于数据的正常工作是必不可少的。
我还读到了在后台使用单独的托管对象上下文的选项。这样做的问题是，即使是这个背景上下文也需要花费太长的时间才能使用。如果用户尝试运行搜索，他或她仍将永远等待该上下文加载。当用户决定在搜索字段中输入什么内容时，我可能会为自己争取几秒钟，但我不能拖延25秒。
我注意到，一旦将数据导入到持久存储中，即使是在与其他表无关的表上进行搜索(并且只有1000个对象)，也需要很长时间才能加载。原因似乎是协调器检索本身很慢，而不是实际的fetch或上下文。
有谁能给我指出解决这个问题的正确方向吗？谢谢!
回答 2
Stack Overflow用户
发布于 2016-11-17 05:18:07
在创建数据模型之前：
如果要存储大型对象，如photos__、audio或video__，则需要非常小心地设计模型。
要记住的关键点是，当您将托管对象带入上下文时，您正在将其所有数据带入内存。
如果大照片位于从驱动表视图的同一实体中剪切的托管对象中，则性能将受到影响。即使你正在使用一个抓取的结果控制器，你仍然可以一次加载超过12个高分辨率的图像，这不会是即时的。
要解决此问题，应将包含大型对象的属性拆分为相关实体。这样，大型对象可以保留在持久存储中，并且可以用错误来表示，直到真正需要它们。
如果需要在表视图中显示照片，则应改用自动生成的缩略图。
Read the whole article
Stack Overflow用户
发布于 2017-08-07 15:20:34
你可能认为PSC是罪魁祸首，这有点言过其实了。CoreData的幕后工作比显而易见的要多得多-- PSC非常灵活，必须进行指导。
对于您指定的数据大小(18K)，一种实际的方法是专注于模块化获取请求模板的逻辑，并针对特定大小的情况进行验证(考虑小型、中型、大型XtraLarge等)。
反规格化数据的建议没有考虑到使数据进入完全反规格化状态的开销，以及(有时)反规格化的意外副作用是稀疏性(当然，除非您有非常具体的模型)。
由于您事先通常不知道将访问和修改哪些数据，因此请在中心任务和任何子任务之间建立一对多关系。这将释放对数据访问的一些限制。
您始终可以让您的最终用户选择他们希望如何处理较大的数据集。
https://stackoverflow.com/questions/32914291
复制相似问题
腾讯云开发者
