Yes IMO thats good, factor out binary data. It actually ends up
being faster in the long run. Thats assuming that those 1byte values
are going to be longer than just.... one byte. Right?
Well... No, the one byte values are just one byte. That's all that's
logged, that's all I need to store. Hence the question.
To give a bit of context this is a 'viewer/library' type app, for data
that logged by an embedded device. So it's going to be drawing graphs
of this data typically. The reason the samples are just a single byte
each is because the memory on the device is limited (16Kb).
Have you seen the benchmarks on CoreData on Leopard? They are wicked
fast.
I wouldn't be worried.
I haven't actually. It would be interesting to see numbers, but can't
find any myself.
Lets say, for some analysis you want to do later, you want to grab
all samples, but you don't need the log information... well, how do
you do that efficiently if they are the same entity? (This is
assuming the aLog entity ends up having lots of fields populating it)
I'm not seeing myself doing that type of analysis, but I agree, it
makes sense if you are doing that kind of thing.
...and Yes, the log has a lot more information in it that more suited
to core data. A lot of who, what, where type stuff that naturally fits
into standard field types.
It's just this one property of the log. It just seems wrong to be
creating so many objects (up to 16 thousand per log), If I can store
the data in a single 16Kb BLOB, that's got to be more efficient than
16K objects, each being 10+ times the size.
Especially if you're talking about retrieving 16K objects to draw a
single graph.
Any suggestions?
Your original idea, I think is better.
Thats just my opinion though!
Fair enough. I have a feeling this might be the sort of thing that I
have to try both ways and see how it does.
Paul
_______________________________________________
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
