我在 iPhone 平台上的 Objective-C 中有一个对象图，我希望在关闭应用程序时坚持闪烁。该图有大约 100k-200k 个对象并包含许多循环（按设计）。我需要能够尽快读/写这个图表。
到目前为止，我已经尝试过使用 NSCoder。这不仅与循环有关，而且还需要很长时间和大量内存来持久化图形 - 可能是因为在后台使用了 XML 文档。我也使用过 SQLite 数据库，但单步执行这么多行也需要大量时间。
我曾考虑使用 Core-Data，但担心我会遇到与 SQLite 或 NSCoder 相同的问题，因为我相信 core-data 的后备存储将以相同的方式工作。
那么有没有其他方法可以以轻量级的方式处理这个对象图的持久性 - 理想情况下我想要像 Java 的序列化这样的东西？我一直在考虑尝试Tokyo Cabinet或将一堆 C 结构占用的内存写入磁盘——但这将是大量的重写工作。
我建议重写为 c 结构。我知道这会很痛苦，但它不仅会很快写入磁盘，而且性能应该会更好。
在任何人不高兴之前，我并不是说人们应该总是使用结构，但在某些情况下，这实际上对性能更好。特别是如果您一次将内存预先分配在 20k 个连续块中（使用指向块的指针），而不是在重复循环中创建/分配大量小块。
即，如果您的循环不断分配对象，那将减慢它的速度。如果您预先分配了 1000 个结构并且只有一个指针数组（或单个指针），那么这会快很多。
（我遇到过这样的情况，即使我的桌面 Mac 也太慢了，并且没有足够的内存来处理连续创建的数百万个对象）
我强烈建议您再看一下 Core Data，而不是自己动手。Core Data 是从一开始就为持久化对象图而设计的。一个基于 NSCoder 的存档，就像您描述的那样，要求您将整个对象图保存在内存中，并且所有写入都是原子的。Core Data 根据需要将对象带入和带出内存，并且只能将图形中已更改的部分写入磁盘（通过 SQLite）。
如果您阅读Core Data Programming Guide或他们的教程指南，您会发现他们在性能优化方面投入了很多心思。如果您遵循 Apple 的建议（这似乎违反直觉，例如他们建议在某些时候对您的数据结构进行非规范化），您可以从数据模型中挤出比您预期更多的性能。我见过一些基准测试，在这些基准测试中，Core Data 在您正在查看的大小的数据库中轻松击败了手动调整的 SQLite，以实现数据访问。
在 iPhone 上，当使用控制 fetches 的批量大小和 NSFetchedResultsController 中一个非常好的帮助类时，您也有一些内存优势。
构建图形的原理证明核心数据实现以将其与现有数据存储方法进行比较应该不需要那么长时间。