Re: core data, binary objects and efficiency
Re: core data, binary objects and efficiency
- Subject: Re: core data, binary objects and efficiency
- From: Evadne Wu <email@hidden>
- Date: Thu, 21 Jul 2011 00:24:18 +0800
Good to know; keep in mind that FileBlob and Audio are entity names I conjured out of thin air and you will have to implement them. :)
-ev
On Jul 20, 2011, at 23:58, Roland King wrote:
> Thanks - I'll look up FileBlob when I re-download all my tools .. I upgraded to Lion and didn't think about the consequences!
>
> On Jul 20, 2011, at 11:46 PM, Evadne Wu wrote:
>
>> I still recommend files if the object is not very, very negligibly small, or if there is going to be hundreds of them. Core Data SQLite fetching is all-or-nothing — either you only have the object ID or the entire row is awaken from fault. You can use (for example) a FileBlob entity which is related to the Audio entity, though.
>>
>> -ev
>>
>> On Jul 20, 2011, at 19:50, Roland King wrote:
>>
>>> 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
>>
>
_______________________________________________
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