Re: Re: CoreData, reset a persistent store
Re: Re: CoreData, reset a persistent store
- Subject: Re: Re: CoreData, reset a persistent store
- From: "Shawn Erickson" <email@hidden>
- Date: Wed, 15 Nov 2006 16:37:38 -0800
On 11/15/06, Pierre Chatelier <email@hidden> wrote:
> If you look at the code, I negated the call (![object isFault])
> which means they are fully realized hence your memory consumption.
Yes, we agree on that
> These objects either are already in memory or are some how firing
> on the retrieval
Since they were fetched, yes, they must be in memory; they can be
faults (and they are), but the data is cached and firing the fault
costs almost nothing.
> Fetching takes minimal memory and time, it is the firing of the
> fetch into a fully realized object that costs the time and memory.
Here we disagree !
My opinion comes from the following documentation : CoreData
Programming Guide > Faulting and Uniquing > Realizing a managed object
we can read :
1)If you execute a fetch using executeFetchRequest:error:, this
always results in a round trip to the persistent store to fetch the
data. The objects returned in the results array are fully realized,
and their data is stored in a cache (held by the persistent store
coordinator).
This implies that you are fully loading all objects of entity kind
"CachedFeatures" from the persistent store (loading from disk) to just
go an delete them since you are using executeFetchRequest:error:. You
are not utilizing any cache for this fetch (but you are getting the
cache populated). This is likely unneeded overhead.
Stepping back ... what are "CachedFeatures" objects? Do you even want
the data those objects contain in the persistent store? If not the
consider making its fields transient.
-Shawn
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden