core data, binary objects and efficiency
core data, binary objects and efficiency
- Subject: core data, binary objects and efficiency
- From: Roland King <email@hidden>
- Date: Wed, 20 Jul 2011 19:50:33 +0800
In my iOS app, using core data, one of my model objects is short audio clips, 2-10 seconds worth of reasonably low quality mono audio. Not huge, but not tiny either. Currently I'm using a binary property in my core data model to store them. I've read the documentation and made sure the audio clips are a separate entity with a 1-1 relationship so they can be faulted in and out again, and I'm keeping some basic metadata about them in my data object to avoid faulting them in until I really need the audio (eg I keep the length of the clip in a separate property for display without having to load the data.
Does anyone have any insight into whether sqlite backing core data is an efficient way to store binary data? However I store it it's going to take space up in flash memory on the device, I know that if I offloaded it to a file in the application's documents directory the file will be the length of the data (plus a very small overhead), which is about as well as I can do, but I'll have to deal with the housekeeping issues of making sure core data and the filesystem are in sync, including after syncs, so I'd like to just leave it in sqlite and let coredata worry about it; core data is good at that stuff.
Has anyone any experience of performance or space efficiency issues I'm likely to run across doing it this simple way? eg if sqlite adds a large overhead to BLOBs, I won't use it, or if it's insanely much slower than pulling from a file, I won't use it and will do the work to store the assets separately.
Thanks
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden