我一直在使用Core Data开发一个Cocoa应用程序。最初一切似乎都很好，但是当我向应用程序添加数据时，我发现初始数据窗口需要很长时间才能加载。为了解决这个问题，我转移到另一个没有数据的启动窗口，所以启动很快。但是，无论我做什么，我的第一次获取和我第一次尝试加载数据窗口（带有表视图）总是很慢。 （也就是说，如果我慢慢地提取然后请求数据窗口，那么第一次这两者都会很慢。）之后，性能是可以接受的。
我通过我的应用程序进行了跟踪，发现虽然我可以快速完成程序，但无论如何，检索持久存储协调器的步骤都非常慢......使用旋转的沙滩球可以经过15 - 20秒。
我在其他地方读过我可能想要对数据进行非规范化。我认为这不够。早期版本在实体之间远没有那么“相互联系”，而且在启动时仍然是一个slu ..现在我正在查看可能有高达18,000个托管对象的实体。一些关系对于使数据正常工作至关重要。
我还读到了在后台使用单独的托管对象上下文的选项。这个问题是即使这个背景环境也需要很长时间才能使用。如果用户尝试运行搜索，他或她仍将永远等待加载该上下文。当用户决定在搜索字段输入什么内容时，我可能会花几秒钟买自己，但是我不能拖延25秒。
我注意到，一旦将数据导入到持久性存储中，即使在与其他表无关的表上进行搜索（并且只有1000个对象），仍需要花费很长时间才能加载。原因似乎是协调器检索本身很慢，而不是实际的提取或上下文。
有人能指出我如何解决这个问题的正确方向吗？谢谢！
答案 0 :(得分：0)
在创建数据模型之前：
如果您要存储大型对象，例如照片，音频或视频，则需要非常小心模型设计。
要记住的关键点是，当您将托管对象带入上下文时，您将其所有数据都带入内存。
如果大型照片位于从驱动表视图的同一实体中剪切的托管对象中，性能将受到影响。即使您使用的是获取的结果控制器，您仍然可以同时加载十几个高分辨率图像，这不是即时的。
要解决此问题，应该将包含大型对象的属性拆分为相关实体。这样，大型对象可以保留在持久性存储中，并且可以由故障代表，直到他们真的需要。
如果您需要在表格视图中显示照片，则应使用自动生成的缩略图图像。
答案 1 :(得分：0)
你可能会超越自己，认为PSC是罪魁祸首。 使用CoreData后，幕后工作的情况比显而易见的要多 - PSC非常灵活，必须有指导 对于您指定的数据大小（18K），一种现实的方法是专注于模块化获取请求模板的逻辑和特定大小案例的验证（想想小型中型大型XtraLarge等）。
对数据进行非规范化的建议没有考虑到使数据进入完全非规范化状态的开销，加上（有时）非规范化的非预期副作用是稀疏性（除非你当然有非常具体的模型）。
由于您通常事先不知道将事先访问和修改哪些数据，因此在您的中心任务和任何子任务之间建立一对多的关系。这将释放对数据访问的一些限制。
您始终可以让最终用户选择他们想要处理更大数据集的方式。