Conceptually, you should treat NSOperations as if they were on a
separate thread. The OS may take certain liberties with
implementation details based on system load and other factors, but
basically NSOperations might as well be described as a light weight
mechanism for creating threaded tasks.
Importing tasks are often easily parallelizable by simply importing
1/Nth of the data on a thread/operation. Here's an excerpt of some
code I've been working with recently. It's GC and non-GC compatible,
and has 3 implementations for comparison: NSOperation, NSThread, and
boring serial code. As you can see, the NSOperation version is
basically the same in terms of thread handling, but NSOperationQueue
provides some convenient out-of-box handling for finding out when the
tasks are complete. The NSThread code has whacky NSConditions and
memory barriers.
The key to making this pattern useful is that each element in the
work queue ('keyQueues' below) is sufficiently large to be worth the
overhead of queuing up. In this sample code, each key is a file
path, so this is importing from a directory of files, importing
'maxCores' files simultaneously.
This division of labor doesn't work if the data in each 1/N sets has
relationships to data in other import groups.
NSPersistentStoreCoordinator* mainPSC = [[appDelegate
managedObjectContext] persistentStoreCoordinator];
NSPersistentStoreCoordinator* psc =
[[NSPersistentStoreCoordinator alloc]
initWithManagedObjectModel:[mainPSC managedObjectModel]];
[psc addPersistentStoreWithType:NSSQLiteStoreType
configuration:nil URL:[[[mainPSC persistentStores] lastObject] URL]
options:[NSDictionary dictionaryWithObject:[NSDictionary
dictionaryWithObject:@"0" forKey:@"synchronous"]
forKey:NSSQLitePragmasOption] error:nil];
// we disable synchronous because if an import fails, we can
delete the file and re-import.
// if you can't just delete the file, don't do this