Re: Itunes structure
Re: Itunes structure
- Subject: Re: Itunes structure
- From: Allan Odgaard <email@hidden>
- Date: Tue, 6 Apr 2004 01:40:39 +0200
On 5. Apr 2004, at 23:11, Jeremyah Payne wrote:
Well I guess thats what I was wondering, Say I have some 6-7000 items
like a nice sized itunes database. Probably about 7.5 MB. IS a file
that is written out to XML like the itunes database dump fast enough
using the built in parser to a dictionary?
As hinted, my library is 9 MB and takes 5 seconds to load. That is on a
733 MHz G4. I would say that this is too slow when evaluating the xml
parser in NSDictionary (or Cocoa/CoreFoundation), but OTOH I would also
say that you should stick with this -- I doubt your database will be
this big right away, I doubt that even 2-3 seconds on startup will be
that noticeable for a game which are generally not known for their
instant startup!?! and by keeping your data as xml you do not place
yourself in a situation where you can't change it in the future, heck
you may even write your own (faster) xml parser which does the same as
"dictionaryWithContentsOfFile:" if it turns out to be a problem.
There is no reason to start your game by spending a week on tuning a
parser... what should be the goal is to be able to change
implementation in the future, that means a format which is *easy* to
parse, and a format which is not tied to the particular architecture
(or C structs) which you are working with.
Flash (SWF), GIF and ID3 (v2.x) are all horrible formats in this
regard, apart from the first two being little endian, then they all
have various bits which decide the length of other fields, wether or
not some fields are present and so on, effectively this requires that a
lot of "knowledge" about the format be expressed in actual code, as
many parts of the format have their own rules and thus cannot be
handled in a uniform manner, contrary to e.g. xml or IFF, which are
generic formats with few rules that allow for rather simple parsers,
written entirely w/o knowledge of the actual data stored in the format.
It is definitely the latter you should strive for in your format
design. The advantage with xml is threefold, 1) you have many standard
tools which already understands it (like NSDictionary, Property List
Editor etc.), 2) it is human readable, allowing e.g. your users to make
batch changes to your files using normal editors (Power of Plaintext),
and 3) you can add new properties to existing files without breaking
compatibility.
If speed/size becomes a problem and you do not need the advantage of
plain text, I would suggest looking into IFF, mostly famous on the
Amiga, but there is actually a lot of stuff based upon/inspired by that
format, like PNG, AIFF and Microsoft did a little endian version they
named RIFF on which AVI and WAVE are based.
Btw: you might find the info at
http://xmlsucks.org/but_you_have_to_use_it_anyway/ interesting -- there
is also a link to
http://www.xmlsuck.com/ which has a list of
alternative formats, but that link is currently broken at my end.
[...] I was hoping to use this same file in relation to the game as
well so it could look up the attributes from the library. So i could
have a weapon class, and then upon init it looks up they key it is
passed and can grab the necessary attributes for it.
Unless your library grows larger than e.g. 20 MB then I think you
should keep the structure of the library on disk separately from the
structure of the library in memory.
The library on disk should be easy to parse and easy to write out. The
library in memory should be easy to query.
Btw: there might be better forums for questions like these.
** Cocoa FAQ: <
http://www.alastairs-place.net/cocoa/faq.txt> **
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.