Tag: 可伸缩性

NSManagedObjectContext保存性能显着降低

当它试图从服务器发送的数据构build初始数据库时，我遇到了基于CoreData的iOS应用程序的问题。 基本上，服务器发送1MB大小的对象（每块大约3000个），iOS客户端将它们反序列化并将它们写入磁盘。 我所看到的是，前面的8个区块（44个区块）一切都很顺利，然后性能急剧下降，每个区块开始花费越来越长的时间，如下图所示。 几乎所有的时间都在[NSManagedObjectContext save]被使用，就像你在Instruments分析数据中看到的一样，但是由于某种原因，它似乎已经不在100％的CPU上运行，就像它正在等待磁盘I / O或者其他的东西。 关于我如何做这件事的一些重要事实： 每个块在自己的NSManagedObjectContext都有自己的NSAutoreleasePool ，因此在处理块之间没有对象build立在非刷新的上下文中。 在任何上下文中都没有设置NSUndoManager 。 没有mergeChangesFromContextDidSaveNotification:继续（即块的上下文没有把他们的变化推到“主”的上下文） 我在iOS 4.3上使用基于SQLite的数据存储。 正在写入的logging确实有索引。 整个同步作业在单个GCD后台线程（即dispatch_queue_create()和dispatch_async() ）上处理。 我不知道为什么表演突然脱落，或者可以做些什么来解决这个问题。 我捅了一下，看了下面的内容，但是还没有什么可以跳出来的： http://cocoawithlove.com/2008/03/testing-core-data-with-very-big.html 保存ManagedObjectContext的性能取决于包含的（不变的）对象的数量？ 任何想法或指针，使这个应用程序扩展到数据库100,000logging将不胜感激。 编辑 – 额外统计 这个Instruments图表显示了与上面相同的模拟（在iPad2上），但包括了磁盘活动统计信息，您可以很清楚地看到，所有“不在100％CPU”运行的时间似乎都被写入磁盘。 我也跑在iOS模拟器上运行相同的同步尝试。 除了包含对象ID的字典（随着时间的推移略微增长（但这些不是CoreData对象或任何会影响保存的对象，它们只是NSNumbers）），每个块的总体内存使用量或多或less是不变的。 这个字典与整个堆相比是less量的内存，所以问题不是内存不足。 这个testing的有趣之处在于CoreData Save工具报告连续保存的时间大致相同，这显然与第一组结果中的CPU分析信息冲突。 似乎CoreData认为将更改推送到数据库需要花费相同的时间，但数据库本身（即SQLite）突然花费很多时间才能将这些更改实际传输到磁盘。