Fixing the iLife Backing Store

ORA blog: Time for iLife Apps to Share a Unified Media Database?

To me, all of these database issues point to a similar need — find a more efficient backing store for the iApps. The more I ask around, the more it seems that XML is the smoking gun on iLife performance drags – it’s a great format for interoperability, but horribly inefficient and resource consumptive. Maybe, just maybe, it’s time to reconsider using XML for the iApps. Maybe, just maybe, Apple should consider using some of the highly efficient open source database code out there — MySQL would do nicely I’m sure.

And since the iLife apps are all so wonderfully integrated now, why not place all of my media in a single, integrated media database? Whether such a database would store media objects themselves (allowing full export to original formats of course) or just references to them (with iTunes-style non-breaking inode references) is unimportant to me. With modern Mac hardware, I should be getting modern media database performance where it counts the most — when using my Mac as the digital lifestyle hub it’s touted as.

Music: Frank Zappa :: The Legend Of The Golden Arches

9 Replies to “Fixing the iLife Backing Store”

  1. All these ideas of faster processors or specialized coprocessors ignore that one of the biggest drawbacks of XML are its random-length records.

    Whenever an item somewhere in an XML file is changed, everything after that item needs to be written out to the disk as well! That is just wasteful, and the disk IO is more likely to be the bottleneck than the main processor.

  2. Just because XML has variable-length fields doesn’t mean that Apple’s usage of XML has to also use variable length fields. Apple could just dictate in the DTD/Schema that their XML application (as in application of the standard, not the actual iApp itself) requires fixed field lengths.

    In addition, all of the articles and comments blaming XML for the slowness of the iApps fail to see that it isn’t XML’s fault, it’s Apple’s usage of XML. If they used a better in-memory representation of the data and simply stored it to disk as XML, they could get the speed of whatever data-access methods used in memory and the openness of XML on disk.

  3. XML can specify fixed-length data fields? Wow, I didn’t know that. Thanks!

    /me checks off ‘learn something new’ from today’s To-Do list.

  4. Thanks for the clarification Sean. I didn’t realize that either. Interesting. Good point about in-memory data representation as well – you’re right, there’s no need for that to stay inefficient in memory. Of course, at a certain point you have to declare that a collection is too large to fit in memory, which is my point about keeping an eye on the future.

  5. XML is a flexible datastore. As someone using XML you can simply say “This field must be 80 characters”… Obviously, however, the opposite isn’t as easy to say (if a datastorage format has fixed fields, it’s harder to implement variable-length fields in that format).

    Scot brought up an interesting point with the size of the database in memory, however…

Leave a Reply

Your email address will not be published.