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: Michael Tsai <email@hidden>
- Date: Sat, 3 Dec 2005 20:11:38 -0500
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.
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.
But you seem to be saying that the attribute data is not fetched all
at once, that it hits the database as the user scrolls. How does
that work? Does NSArrayController rely on private API?
--
Michael Tsai <
http://c-command.com>
_______________________________________________
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