Comments on blog.zssz.me: Asynchronous fetch in Core Data

I need to fetch some items in my code and hence it...

2010-03-19T14:07:00.776+02:00

I need to fetch some items in my code and hence it takes time to load a
particular view.Can I fetch them asyn in the background.

Can u please suggest me how to do this?

I can't think of a way how to do this with NSF...

2010-03-13T11:40:37.777+02:00

I can't think of a way how to do this with NSFetchedResultsController. It handles fetching internally.

This is a great idea. Any tips on extending the NS...

2010-03-13T10:57:36.643+02:00

This is a great idea. Any tips on extending the NSFetchedResultsController to make use of the async fetchrequests?

Hi Zsombor, David here again. I hope you don'...

2010-01-15T07:58:30.905+02:00

Hi Zsombor, David here again. I hope you don't mind all the attention with your module. It's great work!

I was able to use your code quite easily. However, I have some interesting restrictions. I want to perform asynchronous search for an iPhone app using UITableView, UISearchDisplayController, their data source delegates, and NSFetchedResultsController. In theory, it should be straightforward to overlay a searchable interface on Core Data objects using these classes.

In my case, I have a "main" entity with about 8400 instances. My goal is to write a full text search for the text associated with each of these. Therefore I've created an indexed searchWord entity that contains associations between a word and the main entity that contains that word. There are about 57000 unique words linked to these 8400 main instances. As you type, I retrieve all the main instances that have searchWords beginning with the prefix typed in the searchBar. (E.g. the mail app provides this kind of text search.)

Anyway, I've been surprised despite much model tweaking, messing around with predicates, and discussions elsewhere (http://stackoverflow.com/questions/1774369/how-to-optimize-core-data-query-for-full-text-search) that Core Data's performance isn't cutting it. Thus, my desire to implement an async fetch.

Because I'm using the NSFetchedResultsController I can't call executeFetchRequestAsynchronously on the moc. But that didn't hurt me too badly. I modified your code to pass the objectIds back. I then gave a fetchRequest to the fetchedResultsController to retrieve the objects from the objectIds.

The good news is that it works! The bad news is that the async code is significantly slower. Of course some overhead is expected because the fetch must be performed a second time to retrieve the objects. But that extra hit was worse than I was hoping. Typically on the iPhone 3GS the async search time was twice the time for blocking code. Although the user interface didn't block -- which is worth something!

You can find a spreadsheet at http://drop.io/asyncCoreData . The increase in running time versus blocked fetches and the increase in running time as a function of number of rows returned are both linear... which we would expect if the query was properly optimized and retrieving objects by objectId is O(N). Unfortunately, in practice it's still slow.

An interesting example of this sluggish performance for searching large Core Data stores is Apple's iTunes search interface on the iPhone. (There's a search bar hidden above the first row.) I have over 6000 songs and the search is asynchronous, but appears snappy, through some tricks. Even if you've chosen the "Songs" tab, the interface will search through artists, albums, and songs. The implementation must be complicated, but the upshot is that when typing the first few characters you can immediately see the matches for artist or album and the song matches display after some delay further down the table. Essentially Apple tricks you into thinking you're getting a snappy result by showing easy matches first (artist and album) and filling in the matches for song titles later.

Ultimately I'm just going to have to implement a limit on my query, but I'm really not happy about that. From a UI experience, it's lame.

I think this problem is a little subtle. I wonder...

2010-01-12T06:28:24.260+02:00

I think this problem is a little subtle. I wonder what those AJAX smarties do for their asynchronous network queries?

You could easily imagine a situation that puts a heavy load on the database, which is already a problem for the iPhone. E.g. I have a database of about 60000 rows and my queries on the ARM can take several sluggish seconds. Thus, if cut-off time is 0.5s and query time averages 5s, then a user could trigger up to 10 concurrent queries. (Note, [NSOperation cancel] does nothing unless the operation regularly checks isCanceled.)

I think this may also be challenging on the iPhone with the conventional table search paradigm using the NSFetchedResultsController. Early typing of one or a few keys will typically return larger result sets, which means passing around large arrays of object IDs. Using the conventional executeFetchRequest, almost all the objects would remain faulted.

An array of, say, 60000 object IDs might require more memory than the handful of in-memory objects from an array of 60000 NSManagedObjects that are mostly faulted?? Putting a limit on the query, though, is a reasonable option - although unfortunately requiring special handling to notify the user of truncated result set.

I suggest you to cancel any fetch if the user modi...

2010-01-11T18:59:52.004+02:00

I suggest you to cancel any fetch if the user modifies the search string and issue a new fetch when there is no editing activity after e.g. 0.5 seconds.

This couldn't be better timed. I'm amazed...

2010-01-11T08:57:50.759+02:00

This couldn't be better timed. I'm amazed that Google caught your post so quickly!

I just finished reading through Apple's Core Data multi-threaded guidelines, looking at NSURLConnection's initWithRequest:delegate:, and thinking to myself that this was how it should be done!

I'm looking to implement real time search as you type. Looking at your code I was first thinking of cancelling any previous fetches if a new key is pressed, but doing that would just discard, not interrupt, outstanding fetches.

Any thoughts on how not to avoid congestion from multiple, simultaneous fetches? Seems like the best approach would be to set a timer for, say, a 1/2 second before firing the async fetch. The timer is invalidated if another key is pressed before the 1/2 second is up.