我在iPhone平台上的Objective-C中有一个对象图,我想在关闭应用程序时坚持闪现。该图有大约100k-200k的对象,并包含许多循环(按设计)。我需要能够尽快读/写这个图。
到目前为止,我尝试过使用NSCoder。这不仅与循环斗争,而且需要一个年龄和大量的内存来持久化图形 - 可能是因为XML文档被用于封面。我也使用过SQLite数据库,但是通过这么多行也需要花费大量时间。
我考虑使用Core-Data,但担心我会遇到与SQLite或NSCoder相同的问题,因为我相信核心数据的后备存储将以相同的方式工作。
那么还有其他方法可以轻量级地处理这个对象图的持久性 - 理想情况下我喜欢Java的序列化吗?我一直在考虑尝试Tokyo Cabinet或将一堆C结构占用的内存写入磁盘 - 但这将是大量的重写工作。
答案 0 :(得分:1)
我建议重新写作c结构。我知道这将是一个痛苦,但它不仅可以快速写入磁盘,但应该表现得更好。
在任何人感到不安之前,我并不是说人们应该总是使用结构,但在某些情况下,这实际上对性能更好。特别是如果你一次预先分配你的内存20k连续块(用指针指向块),而不是在重复循环中创建/分配大量的小块。
即如果你的循环不断地分配对象,那就会减慢它的速度。如果你预先分配了1000个结构并且只有一个指针数组(或一个指针),那么这个数字会大很多。
(我的情况甚至我的桌面mac太慢了,没有足够的内存来处理连续创建的数百万个对象)
答案 1 :(得分:1)
我强烈建议您再看看Core Data,而不是自己动手。核心数据是从persisting object graphs开始设计的。基于NSCoder的存档(如您所描述的存档)要求您将整个对象图存储在内存中,并且所有写入都是原子的。核心数据根据需要将对象带入和移出内存,并且只能将已更改为磁盘的部分写入磁盘(通过SQLite)。
如果您阅读了Core Data Programming Guide或他们的tutorial guide,您会发现他们已经在性能优化方面投入了大量精力。如果您遵循Apple的建议(这似乎违反直觉,比如他们建议在某些时候对数据结构进行非规范化),您可以从数据模型中获得比预期更多的性能。我见过基准测试,其中Core Data轻松地在您正在查看的数据库中轻松击败手动调整的SQLite以进行数据访问。
在iPhone上,在NSFetchedResultsController中使用控件批量大小和非常好的助手类时,你也有一些内存优势。
建立图表的原理验证核心数据实现并将其与现有数据存储方法进行比较不应花费太长时间。