为什么我宁愿为每个新线程或NSOperation创建一个NSManagedObjectContext，而不是在主线程上调用Core Data？ [英] Why should I prefer to create an NSManagedObjectContext for every new thread or NSOperation instead of calling Core Data on the Main thread?

问题描述

一些开发人员已经告诉我，我可以为每个新线程创建一个新的NSManagedObjectContext实例，以使Core Data线程安全。

对我来说，这听起来像是一大堆额外的代码和开销。

有什么原因这个解决方案会坏吗？这里它来：

不是为每个新线程或每个NSOperation创建一个新的MOC，我将在主线程上执行MOC更改，就像我们从UIKit。我只需调用 -performSelectorOnMainThread：... waitUntilDone：YES ，并摆脱所有Core Data并发问题。

优点：$ b​​ $ b - 不必为每个Thread / NSOperation创建一个新的MOC。
- 不必将MOCs合并在一起。
- 确保没有并发问题，因为Core Data停留在主线程上它是安全的。

缺点：$ b​​ $ b - 调用像 -performSelectorOnMainThread：... waitUntilDone：YES 看起来很丑陋，很难阅读。
- Thread / NSOperation被阻塞。但在现实中，系统不能一次做多个事情。在我的情况下，核心数据部分不是性能瓶颈。

你觉得怎么样？这是值得进一步探索吗？为什么你仍然喜欢为每个新的Thread / NSOperation创建一个MOC，然后处理合并？

解决方案

磁盘访问是昂贵的 - 我们已经告诉...

如果您提取或保存大量数据，则 是在NSThread / NSOperation上使用单独的MOC的一个优点。加上视图转换，这可以很好地改善你的应用程序的速度的感觉，因为主线程只执行UI转换的东西。

I认为您可以通过测量实际花费多少时间访问您的商店与您的UI响应（IIRC：尝试CoreData和CoreAnimation Instruments）来找到您的答案，并比较两种情况：每个线程使用不同的MOC与调用 -performSelectorOnMainThread：... waitUntilDone：YES

如果保存在后台线程，您还需要考虑当您的应用程序在保存操作正在进行时被终止时会发生什么。后台线程立即被杀死，而看门狗等待5秒钟，主线程完成。

Some developers already told me that I can create a new NSManagedObjectContext instance for every new thread, to make Core Data thread-safe. Then I would just have to take care of the merging afterwards.

For me, this sounds like A LOT of extra code and overhead.

Is there a reason why this solution would be bad? Here it comes:

Instead of creating a new MOC for every new thread or for every NSOperation, I would perform MOC-changes on the Main Thread, just like we know from UIKit. I would just call -performSelectorOnMainThread:...waitUntilDone:YES and get rid of all Core Data concurrency issues.

Pros: - Don't have to create a new MOC for every Thread / NSOperation. - Don't have to merge MOCs together. - For sure no concurrency issue since Core Data stays on the Main thread where it is safe.

Cons: - Calls like -performSelectorOnMainThread:...waitUntilDone:YES look ugly, hard to read. - Thread / NSOperation gets blocked. But in reality, the system can't do multiple things at once anyways. In my case, the Core Data part is not the performance bottleneck. It's the heavy calculations around it that go in a background thread or NSOperation.

What do you think? Is this worth exploring further? Why would you still prefer to create a MOC for every new Thread / NSOperation and then deal with merging? What's the advantage of this compared to doing it on the Main thread?

解决方案

"Disk access is expensive" - we've been told...

If you fetch or save lots of data, there is an advantage of using a separate MOC on a NSThread/NSOperation. Coupled with a view transition, this can well improve the perception of "speed" in your application, since the main thread is left to perform only the UI transition stuff.

I think you could find your answer by measuring how much time you actually spend accessing your store vs your UI responsiveness (IIRC: try the CoreData and CoreAnimation Instruments), and compare both scenarios: using a different MOC per thread vs. calling -performSelectorOnMainThread:...waitUntilDone:YES

BTW, if you save on a background thread, you also need to consider what happens when your app is terminated while a save operation is in progress. Background threads get killed right away, whereas the watchdog waits 5 seconds for the main thread to finish up.

这篇关于为什么我宁愿为每个新线程或NSOperation创建一个NSManagedObjectContext，而不是在主线程上调用Core Data？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！