• 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
Re: Threads and Core Data, bindings results in view corruption
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Threads and Core Data, bindings results in view corruption


  • Subject: Re: Threads and Core Data, bindings results in view corruption
  • From: Ben Trumbull <email@hidden>
  • Date: Mon, 31 Mar 2008 14:37:11 -0700

At 4:05 PM -0400 3/31/08, Ben Lachman wrote:
You also should try using an SQLite store. It will be faster than a binary store for saving incrementally since it only touches part(s) of the file.

Binary store ? Binary store ?

The xml, binary, and custom atomic stores are all atomic. The entire file gets read or written. No partial loading, no partial saving. Those 3 stores behave similarly to NSKeyedArchiver.

They act a lot like document based apps such as Text Edit. No incremental operations.

Having multiple threads save to an atomic store is kinda crazy. Definitely highly discouraged.

Even without multiple threads, the sqlite store outperforms them in straight up races once you get to a few hundred records. More or less depending on just how big your records are. It performs comparably on smaller data sets, and is only slower for very tiny sets (like 10).

On 10.5, with Core Data's SQLite store, I get insertion speeds of about ~29,000 rows/s on a quad core Mac Pro, and fetch speeds of ~800,000 rows/s.

David, your morale should improve dramatically by changing that 1 argument in -addPersistentStore:...

Once you get to one thousand record, the only reason to use a binary store is if you really really need that atomic behavior, and you're willing to pay for it.

For example, if you require soft real time constraints, and loading the data into memory is more desirable than accidentally firing a fault at any time in the future.

Similarly, the xml and custom atomic stores are for managing an external, possibly public, data format. Not for performance, not for concurrent operations.
--


-Ben
_______________________________________________

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


References: 
 >Re: Threads and Core Data, bindings results in view corruption (From: David <email@hidden>)
 >Re: Threads and Core Data, bindings results in view corruption (From: Jeff LaMarche <email@hidden>)
 >Re: Threads and Core Data, bindings results in view corruption (From: David <email@hidden>)
 >Re: Threads and Core Data, bindings results in view corruption (From: Jeff LaMarche <email@hidden>)
 >Re: Threads and Core Data, bindings results in view corruption (From: Ben Lachman <email@hidden>)

  • Prev by Date: linked list problem
  • Next by Date: Re: Problem with setting color in NSBitmapImageRep
  • Previous by thread: Re: Threads and Core Data, bindings results in view corruption
  • Next by thread: Re: Threads and Core Data, bindings results in view corruption
  • Index(es):
    • Date
    • Thread