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 (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
