并行化核心数据导入 - 生产者/消费者

Question

我正在寻求提高我的Mac OS X应用程序（日志文件解析器）的性能，并且不介意寻求关于并行化导入过程的技术的一些指导。我的应用程序的基本要点是，它会获取一个日志文件（可能是数十万行），它会读取，解析并存储到Core Data数据库中，以便进行后续过滤/分析。

我正在使用多个父/子托管对象上下文来确保从主线程进行导入，如下所示：

NSPrivateQueueConcurrencyType (root MOC)
            ^^
NSMainQueueConcurrencyType    (UI MOC)
            ^^ 
NSConfinementConcurrencyType  (import MOC)

从数据库的角度来看，这非常有效，我现在正在寻求提高每行可以进行标记化/解析的速度。我花了很多时间在仪器上，我相信标记化/解析单个日志行的路径得到了很好的优化。但是，遍历每一行是（当前）一个顺序过程...我想要做的是读取一个线程上的行，然后将每一行交给工作线程池进行处理（经典生产者/消费者情况）。

我认为可以作为候选人的几种模式是：

• 创建一个NSConfinementConcurrencyType MOC池，然后当我遍历这些行时，在[moc performBlock:]中调用我的行解析逻辑。看起来相当简单，但是每隔几千块记录调用[moc save:]并且知道所有块最终都已完成时可能会有一些乐趣（我有一些汇总级别信息需要在所有行中进行整理）已被导入）。
• 为每一行创建一个NSOperationQueue并输入NSOperation。为每个行创建一个NSOperation似乎有点笨拙（记住每个日志文件中可能有数十万行）。还需要一种方法来确保每个操作都有一个有效的MOC（再次，为每个行创建一个新的子MOC似乎有点过分）
• 使用GCD。使用像dispatch_group_async之类的东西在GCD块中启动操作给了我很好的方法来了解事情何时结束，但是，我仍然需要一种分配MOC并确保GCD块执行正确的方法MOC线程。可能在[moc performBlockAndWait:]内使用dispatch_group_async，但我对混合同步和异步调用的死锁有点警惕。

对各种方法的缺陷/好处有何想法？我错过了什么方法？正如我之前所说，它似乎是一个相当经典的制作人/消费者问题（我可能倾向于将GCD作为解决方案），然而，MOC管理的额外皱纹让我停下来思考。

任何人都走在这条道路上并有任何想要分享的想法吗？

非常感谢。 克雷格