Re: more than one plist in a file.
Re: more than one plist in a file.
- Subject: Re: more than one plist in a file.
- From: Paul Thomas <email@hidden>
- Date: Fri, 2 Dec 2005 15:59:20 +0000
On 2 Dec 2005, at 14:16, I. Savant wrote:
Unless I've completely missed the mark, the OP is correct. His
requirements are efficient and immediate log entry appending (I'm
assuming he means that the logs will become quite large), the
ability to read the data back into the app easily *and* human
readability.
The reading ability would definitely be 'automagic' by going the
Core Data route. Unfortunately, the other two probably aren't going
to work together in this case.
For efficiency, he could use the SQLite store. This would make
appends quite smooth for huge log 'files'. Unfortunately, this
would render it non-human-readable.
For human readability, he could use an XML store. Unfortunately,
that throws efficiency for huge loge files right out the window.**
Appending 'events' to the XML store and immediately saving it each
time (the expected behavior of any logging system, I'd argue) could
become quite a hungry beast quite quickly, depending on how fast
the log is filled. Perhaps rotation would help (if the logs are
filled more slowly) but is not always desirable (ie, more of a pain
to 'import' with other tools). But even then, it's not scalable
because if their volume ever increases, they'd be stuck finding
another solution or throwing heavier hardware at it to increase
performance.
Considering this, I don't believe Core Data is a good fit in this
particular situation, with these specific requirements. (again, **)
** Note - if I misunderstood the performance issues with XML
stores, PLEASE correct me. I'd love to use XML stores for my own
frequently-saved, large data sets for exactly the same reason -
human readability (along side much more universal machine
readability). Seriously - I have no pride; I'd love to hear
opinions about XML store performance for frequent appends. You have
no idea how much I want to be wrong here. ;-)
You've pretty much hit the nail square on.
I could live with the overhead of XML markup tags (<string> etc.) but
not the full header for each entry. And I'd have to do that because
XML is closed and you can't just append items.
Besides, the point is moot if the NSPropertyListSerialization can't
move any kind of read pointer. So I'm going to implement with a full
plist writing implementation and then measure how bad the performance
is. If it's unacceptable, then I'll have to reinvent the persistence
wheel but it can wait. You know what they say about premature
optimisation...
Thanks for your time,
Paul.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden