CODEWITHSUNDEEP
iosobjective-cperformancesqliteplist
Majster
Majster

Reputation: 3701

SQLite vs Plist performance

I have some data that has to be stored locally in my app and I was wondering what is the best way to store it (looking from the performance perspective). There is not much data nor is there little. Looking from a plist perspective data could look like this:

 -root
    -main_block1
        -sub_block1
            -some_data
            -some_data
            -some_data

        -sub_block2
            -some_data
            -some_data
            -some_data

        -sub_block3
        -sub_block4
        ...
        -sub_blockn
    -main_block2
    -main_block3
    ...
    -main_blockn

There will be approximately 3-10 (13-15 max I guess) main blocks. Consider main block as a dictionary with around 10 characters for the title. In each main block there will be from 1-10 (max 10) sub blocks which are also dictionaries. Each sub block will contain some plain text data. Strings with no more than 100 characters (or maybe 200-300).

I will need to read this data and also mingle it around a bit (swap a main block or two and swap a sub block or two).

I need it to be as fast as possible since I already have quite some stuff in my app so I was wondering what should I use? A Property List file or a SQLite database?
SQLite database is basically a text file with a code wrapper around it that manipulates its contents so my guess is that in my situation a plist file will be faster...

As said data will not exceed a few ten kilobytes (hope not :P).

EDIT: To add a bit of information: main blocks are views that need to be loaded in this order and sub blocks are subviews on main views that need to be in this order. Some data is data that will be fed to those views. So order of main views and subviews will be changed from time to time and data for sub views will be reloaded when the user decides to. Hope this helps a bit.

Upvotes: 2

Views: 1153

Answers (2)

Owen Hartnett
Owen Hartnett

Reputation: 5935

SQLite is really intended for searching through record stores, joining data together, and filtering out data you don't need. It sounds like you have a data structure that would fit easily in memory (though you should measure this to see just what you have), requires little editing. That editing will be a headache in SQLite, if you have to change a table's schema. Why not just keep it as a dictionary/array structure, and use the serialization to store it in a file, or even in the user defaults? If you intend to display it in Apple's standard views, where you want one view to immediately show a change made in another view, maybe CoreData is your friend.

Upvotes: 3

Hot Licks
Hot Licks

Reputation: 47729

It depends. If you will constantly re-reference the data structure, and will reload the plist each time, then a SQLite DB (that you leave open) would be faster. If you only load and reference the data once then plist wins. And, of course, you can use Core Data for simple SQLite functions.

Upvotes: 3

Related Questions