NSArray vs. SQLite for Complex Queries on iPhone

Developing for iPhone, I have a collection of points that I need to make complex queries on. For example: "How many points have a y-coordinate of 10" and "Return all points with an X-coordinate between 3 and 5 and a y-coordinate of 7".

Currently, I am just cycling through each element of an NSArray and checking to see if each element matches my query. It's a pain to write the qu开发者_JAVA技巧eries though. SQLite would be much nicer. I'm not sure which would be more efficient though since a SQLite database resides on disk and not in memory (to my understanding). Would SQLite be as efficient or more efficient here? Or is there a better way to do it other than these methods that I haven't thought of? I would need to perform the multiple queries with multiple sets of points thousands of times, so the best performance is important.

You can use SQLite as an in-memory database. Just initialise it with the filename ":memory:". SQLite will never perform as well as carefully hand-crafted data structures, due to the overheads of the SQL engine and the dynamic type system. But it might still yield very good results with the convenience and full generality of ad hoc SQL. You can even add indexes to in-memory databases to help with query performance.

If performance is your key criteria then you should be using an array of floats to represent your points rather than an NSArray as that is as fast as it is going to get. If you really want to use sqlite, it can be configured to run as an in memory database, see here for the details.

If you really want to get down and dirty with performance you might look into using LLVM to dynamically generate machine code to iterate over your data set, but that is probably over kill ;)

I think Core Data and SQLite both implement caching, so that you get the ease of querying and the power of a relational database. Should be worth investigating.