Re: [CORE DATA] BackgroundFetching app explanation, and more...
Re: [CORE DATA] BackgroundFetching app explanation, and more...
- Subject: Re: [CORE DATA] BackgroundFetching app explanation, and more...
- From: Scott Ellsworth <email@hidden>
- Date: Mon, 19 Dec 2005 12:58:52 -0800
On Dec 19, 2005, at 10:38 AM, Aurélien Hugelé wrote:
i have about 50 000 objects to fetch and unfault the first time the
user ask for them. The objects are displayed sorted by date,
descendingly, So that he immediatly sees the most recent entries.
I would suggest examining your data design again. How many of your
50k objects will be on screen at any one time? If you can let the
array controller and predicate drive grabbing just what they need,
then your life is simplified.
For most apps, the right number is measured in hundreds, not 50k.
(And I know there are exceptions, and that yours might be one of
them. Still, if there is any way to let CD work the way it is
designed to, you will do less work.)
Core Data, especially the sql store, is designed to give you a light
memory footprint when it works with array controllers. Thus, if you
have an array controller that feeds a predicate with the right sort
order, when you show the user the hundred or so rows that fit on
screen, only those hundred need to be pulled from the store. More
are grabbed when the user scrolls.
From what you said, the sort order is based on a date column, so it
should be doable server side.
That said, you may have to pull all 50k in. One of my programs was
going down a similar road at one time, until I figured out a way to
fix my accesses so I could pull in just the 500 items my user needed
to see for a given screen. Had I not thought of my new data
organization, I would have needed some kind of bulk fetch to get
enough peformance. If this kind of change is not an option for you,
then we need to look at the speed issues you face, and some code
would help. A short example with a 'build' and a 'retrieve' method
that shows the problem would really help us see what is going on.
Scott _______________________________________________
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