编辑滚动文本视图时，Core Data会慢慢爬行

Question

这里有趣的问题：

我有一些连接到Core Data模型的textview。一切都很好，除了一件事。

当我将信息放入textview时，整个应用程序会慢慢爬行，调用beachball。

当我将核心数据工具附加到我的应用程序的进程时，将使用键入的每个字符调用NSManagedObjectContext save。这种滞后使整个应用程序陷入瘫痪。

为了让事情变得陌生，问题并不一致。有时，应用程序决定需要为输入到textview中的每个字符写入保存的文档（SQLite，XML，二进制文件，无关紧要），有时则不会。

有什么想法吗？

Answer 1

更新回复

我正在更新这个答案，以反映现实情况。

正如patrickn在他最初的问题中所说，他正在开发一个基于文档的应用程序，其中包含Core Data。他最终发现该文件为autoSavesInPlace返回YES。事实证明这是默认行为，它似乎对NSManagedObjectContext产生了不良影响。

According to Apple：

  

在Mac OS X v10.7及更高版本中，用户无需保存文档   明确或担心丢失未保存的更改。相反，   系统会根据需要自动将文档数据写入磁盘。您的   NSDocument子类通过重写来选择此行为   autosavesInPlace类方法返回YES。理想的基线   无保存文件是这样的：用户在中查看的文档数据   应用程序窗口始终与磁盘上的文档相同。

听起来不错，但他们也说：

  

在启用自动保存之前，请考虑您的保存性能   应用。如果您的应用程序快速保存，则没有什么理由   不要启用它。但是如果您的应用程序保存缓慢，则启用   自动保存可能会导致定期阻止您的用户界面   储蓄正在发生。

长话短说，如果您正在Lion上开发基于文档的应用程序并且看到可疑的性能，您将需要考虑是否应该为autosavesInPlace返回YES。

原始回复

如果你真的想修复那么你必须找出调用保存操作的内容。这不是正常发生的事情所以我会仔细研究你的代码并在每次调用时设置断点来保存。

运行你的应用程序，你就能找到它发生的位置。

没有理由为什么会随机调用它，但是如果这样做后你发现它仍然存在，那么我会提交错误报告。

Answer 2

我不喜欢这个建议，但如果没有什么更有趣的话，我会回到这个建议。

我建议在Core Data和UITextView之间添加一个层来缓冲信息并偶尔启动Core Data。 （而不是每个字符）