CODEWITHSUNDEEP
ioscore-data
Mehdi Badjian
Mehdi Badjian

Reputation: 71

NSFetchResultController not that responsive for very large coredata database

Im designing a dictionary App, which is having a database of minimum 220,000 entries. First I used a single Entity to store my data then after a weak performance for searching database, I changed my database design to have an Entity based on each Alphabet.

Then again since the method I was using, was to fetch all data matching the search object into an NSArray, my performance was not acceptable (each key stroke made my UIView to freeze for approx 3 sec), So I changed to NSFetchResultController. FRC made my app much more responsive (1-1.5 sec per key stroke) but still this is not acceptable result.

I would really appreciate if you can guide me further so I can increase the performance.

Upvotes: 0

Views: 211

Answers (2)

Jody Hagins
Jody Hagins

Reputation: 28409

Since CoreData is an object graph, you can implement any sort/search algorithm you want. A trie would certainly be good here... and tries are easy to implement.

However, before I did that, I would use the new(er) features of CoreData, and add an index on the attribute you are using for your search.

Using Xcode, bring up your model, and select the your entity. then, on the far right side, in the attributes inspector, right under where you give your entity a name, there is a place to set search indexes. It is called, surprisingly enough, "Indexes."

Add the attribute on which you do all your searching to that. The database will then maintain an index on that field, and when you search it, you will not have to linearly search the entire database.

Upvotes: 0

user23743
user23743

Reputation:

A good data structure for storing and looking up entries in a dictionary is a Trie (or Knuth volume 3 p492). If you want to carry on using Core Data to store your data when you're using this structure, you should implement the structure in a subclass of NSAtomicStore.

Upvotes: 1

Related Questions