views:

77

answers:

1

I'm tinkering around with a iPhone word app where I am using a DAWG structure for finding anagrams from a user defined word bank in real time as the user types. That part works well. As the words are identified, I want to retrieve specific information about each word which I currently have in a plist file (keyed by word). This information needs to be imported and available when the apps starts.

On startup, I can easily ready the plist into an NSDictionary object using initWithContentsOfFile, but this creates a dictionary with ~200,000 key/value pairs. I'm guessing that this is not the best approach as the plist files in txt, bin, and xml format are 2.8 MB, 3.9 MB, and 7.5 MB respectively.

Should I be using Core Data or SQLite? My top priority is performance as I would like to look up the info for literally tens of thousands of results in real time as the user types if possible.

Thanks

A: 

You can only answer performance questions by trying both approaches and profiling (use Instruments.app). That said, there is a lot of Core Data that serves object graph management functionality that it doesn't sound like you need. If what you really want is a key-value store, then using an NSDictionary makes sense. You should compare against a Core Data stack using an in-memory persistent store. There is little reason to go to SQLite or a Core Data persistent store on disk if your goal is maximal read performance and you can fit the entire data set into memory.

Barry Wark