3

I'm building an application which has a "record" feature which records user interaction over time. As time progresses, I fill an array in memory with "state" objects representing the current state of the user input. A typical recording will result in about 5k of these objects.

I then archive this data using NSKeyedArchiver archiveRootObject: toFile:. This works fine, however the file size is very large (3.5 megs or so). My question is this:

Is there any inherent file-size overhead involved in archiving files? Would I be able to save this data using much less disk space if I were to use SQLite, or even roll my own file format? Or is the only way to reduce the disk size of the data going to be to reduce the bit depth of the numbers I'm storing?

morgancodes
  • 25,055
  • 38
  • 135
  • 187
  • Look into the Core Data framework. Apple has a must see video on the topic on the developer website. – Moshe Aug 11 '11 at 14:06
  • Thanks Moshe. Do you think I'll be able to use less disk space by using Core Data rather than NSKeyedArchiver? – morgancodes Aug 11 '11 at 14:28
  • The storage technique isn't going to change the footprint of your data. You'd have to figure out our own way of trimming/compressing the data if you want to reduce the filesize. Using SQLITE vs. core data won't change the amount of space the data takes up, they are just different methods for writing and retrieving said data. You can use up to the storage capacity of the device whatever technique you pick. – mattacular Aug 11 '11 at 15:11
  • Thanks Matt. I realize that Core Data uses SQLite for storage. I'm wondering if there's any difference in the footprint between SQLite storage of data and archiving objects using NSKeyedArchiver. – morgancodes Aug 11 '11 at 15:17

3 Answers3

2

If your concern is performance, Core Data gives you more granularity. You can lazy load and save by parts during app execution vs loading/saving the whole 3.5Mb object graph.

If your concern is file size, this is the binary plist format, and this is the SQLite file format. But more important than the overhead, is how complex is the translation between your object graph and the Core Data model.

You may also be interested in this comparison of speed and performance for several file formats: https://github.com/eishay/jvm-serializers/wiki/ Not sure if everything there has an C, C++ or objective-C implementation.

Jano
  • 62,815
  • 21
  • 164
  • 192
2

3.5 MB isn't a very large file. However, if your app has to load or save a 3.5 MB file all the time, then using Core Data is a lot smarter as this allows you to save only the data that has changed and retrieve only the parts that you're interested in -- not the whole thing every time.

Hollance
  • 2,958
  • 16
  • 15
  • It's going to be 3.5 megs times 10 or so. I need to save about ten different sets of data, and I want to include all of this data in the initial download of the app. – morgancodes Aug 13 '11 at 14:36
  • That's still only 35 MB. For a download that is slightly big, so if you can compress it to less than 20 MB it's only for the better, but as storage on the device it's peanuts. – Hollance Aug 13 '11 at 15:12
0

If storage is the main concern, there would be little difference b/w sqlite and core data.

I had to store UIViewControllers with state in an app, where I ended up not saving the serialized objects but saving only the most specific properties and creating a class which read that data and re-allocated those objects.

The property map was then stored in a csv [admittedly very difficult to manage, but small like anything] and then compressed.

Abhinit
  • 1,016
  • 7
  • 13
  • Thanks for the reply Abhinit. But I'm not asking about sqlite vs core data, I'm asking about NSKeyedArchiver vs. core data. – morgancodes Aug 12 '11 at 15:15
  • Okay. Even NSKeyedArchiver saves whole objects. So it too would not make a lot of difference in the final file size. I think the key here is to save as little data as possible. Unless you absolutely have to save everything that object has. – Abhinit Aug 12 '11 at 15:34