• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Managed-object creation in concurrent NSOperations: Serializing. What to do?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Managed-object creation in concurrent NSOperations: Serializing. What to do?


  • Subject: Managed-object creation in concurrent NSOperations: Serializing. What to do?
  • From: Fritz Anderson <email@hidden>
  • Date: Tue, 05 Nov 2013 13:14:29 -0600

I'm on a MacBook Pro with a 4-core i7.

I'm writing a throwaway command-line tool that builds a Core Data store (SQLite) with (i entity_A) each related to-many to (j entity_B) each related to-many to (k entity_C).

For large j or k, this takes a really, really long time. So I tried this:

- Create an NSOperationQueue, leaving maxConcurrentOperationCount at the default (0), which I understand means that the queue will absorb as many threads as the system can cope with.

- Observe NSManagedObjectContextDidSaveNotification, handled by a method that sends mergeChangesFromContextDidSaveNotification: to the main NSManagedObjectContext.

- In a loop running i times

-- create an NSBlockOperation, with a block that

--- peels off its own NSManagedObjectContext (NSConfinementConcurrencyType) from the common store coordinator,
--- inserts one entity_A
--- cascades to the j entity_Bs and j*k entity_Cs.
--- It saves the MOC at the end of every entity_B loop.

-- Add the block operation to the queue

- Run the main run loop (runUntilDate: 1 second from now) until the queue's operationCount is 0.

I set j and k too high, and had to go home for the weekend, so I've never allowed the process to run to completion.

However, I see this in the debugger's CPU display: For a few seconds, eight threads run concurrently, saturating the processor capacity. Then each thread gets only about 25% duty; no more than two execute at the same time. Obviously, something is serializing the process. I'm guessing that this comes at the merge-changes step, but it's only a guess, and I haven't had time to investigate.

Two-at-a-time processing is better than one-at-a-time, but it's not what I thought I'd asked for.

I have another command-line tool that does saturate the capacity (though it was on a 12-core machine, and I asked for only 6).

Does anyone see what's going on?

	— F


_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden


  • Prev by Date: Re: Mutually exclusive item filtering-comparing
  • Next by Date: Re: Codesigning 3rd party framework
  • Previous by thread: Re: Mutually exclusive item filtering-comparing
  • Next by thread: URLByResolvingBookmarkData: crashes on 10.8
  • Index(es):
    • Date
    • Thread