Re: CoreData - large data set is slow to load on app launch - optimisation tips?
Re: CoreData - large data set is slow to load on app launch - optimisation tips?
- Subject: Re: CoreData - large data set is slow to load on app launch - optimisation tips?
- From: Chris Hanson <email@hidden>
- Date: Sat, 3 Dec 2005 23:25:59 -0800
On Dec 3, 2005, at 5:11 PM, Michael Tsai wrote:
On Dec 3, 2005, at 5:59 PM, Chris Hanson wrote:
The app launches and displays an initial set of Recipes in 2
seconds with 5000 Recipes. How many Recipes are actually fully
realized in memory at that point? And how would increasing the
number of Recipes influence the launch time, all else being equal?
There will be 50 fully-realized Recipes in memory, because the
rest of the Recipes are represented by faults. Only when they're
accessed -- say because the user scrolls the table view -- will
they actually be brought in.
Increasing the number of Recipe instances in the database will
affect the load time, but by a much smaller factor than asserted
above because all of the data for those instances will stay in the
database.
Could you explain the mechanism for that last point? The reason I
ask is that I read somewhere (sorry, can't find the reference) that
-executeFetchRequest:error: fetches all the (attribute) data into
memory and merely defers the full realization of the fetched objects.
Great catch and thanks for doing so! Michael is correct, I'm wrong
on this count. My only defense is that I was replying on an empty
stomach...
In other words, the objects are technically faults until their
attributes have been accessed, but the raw data for their
attributes is in some kind of cache. This allows the faults to be
fired without accessing the database again.
This is correct. It is, in fact, the core of the recommended
approach to fetching in a background thread as documented in the
BackgroundFetching example.
So to recap what Michael is responding to, *correctly* this time:
There will be 50 fully-realized Recipes in memory, because the rest
of the Recipes are represented by faults. However, the data for the
unrealized instances may still be brought in to a cache; only the
realization of the individual faults into full managed objects is
delayed.
Increasing the number of Recipe instances in the database will affect
the load time, but by a smaller factor than one of the previous
posters asserted because only a small number of managed objects will
actually be fully realized while the rest remain faults.
One solution to this illustrated by the BackgroundFetching example.
Rather than having an array controller in your application that pulls
its content directly from a managed object context, you can set its
contentArray to an array maintained by the application and have the
application use a thread to populate this array progressively.
-- Chris
_______________________________________________
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