On Oct 15, 2008, at 17:41, Dave Dribin wrote:
On Oct 15, 2008, at 5:52 PM, Melissa J. Turner wrote:
The downside tends to be more memory use, since you'll have two
copies of all the data for each object that is loaded into both
stacks in addition to the overhead of the stack itself. Stale data
is unlikely to be a problem unless you're expecting to load it
significantly before you actually need it, which would be the same
if you were loading it into a separate context on the same
coordinator.
Okay, great. This sounds ideal. One clarification. When you say
"two copies of all the data", doesn't this happen if you had 1 PSC
and 2 MOCs, too? Each MOC has it's own copy of the data, since they
don't share managed objects, right? Or is there some other data
that is shared in the PSC?
There's data cached down in the store as well, so if you have multiple
copies of a store (multiple stacks), you have multiple copies of the
data. If you have 1 PSC and 2 MOCs, we can leverage private
information about the state of the context and the objects in it to
decrease memory use (write only caching), but with 2 separate stacks,
we lose that ability. Just don't try to load and dirty the world ;-)
The big upside is that it decreases the amount of time your UI
thread will be blocked on reads being done by the background thread.
Precisely. I'm seeing some lock contention between the threads, and
I want to reduce/eliminate that. BTW, this is a SQLite store. Do
fetches do an exclusive SQL transaction, or is that only done for
saves? Just curious if SQLite's locking will affect the threads at
all, as we're seeing some fetches take a relatively long time (~3
seconds). Ideally, the SQLite database won't be locked for that
period, either, which would also block the UI thread.
We only open transactions when we update the database. Fetches take a
read-only lock, so they'll block if there's a writer, and a would be
writer will have to wait for any reads to finish before it touches any
tables the reader is using, but overall you should see better
performance.
+Melissa
_______________________________________________
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]
