Alex headshot

AlBlue’s Blog

Macs, Modularity and More

What is the point of Apple's binary plist format?

2009 Mac Iphone

When Apple created the plist format, it was as a drop-in replacement of the Next-style property lists (as emitted from the NetInfo tools) which were a kind of JSON-like format. Much ado was made at the time that they weren't “proper” XML formats, since the data encoded was an ordered set of typed information rather than information. On the plus side, the schema for plists has remained unchanged for pretty much ever, and all applications use it (for storing their name and version, if nothing else).

Then, in not so early days, Apple released plutil whose only purpose in life was to convert between an XML representation of the file (good, human readable) into an opaque binary format (aka 'binary1'). The suggested rationale behind this was to reduce disk space; though it's quite possible that by storing a set of data-type limited forms in a transparent manner that the deserialisation process might be faster (no entities to worry about, etc).

The problem is that there are better ways of solving the problem, at least from a space-saving perspective. XML files tend to GZip quite well, especially when they're repetitive (as property lists often are), and the resulting space is often much less than the equivalent binary XML form. As a test, I looked at /System/Library/CoreServices/backupd.bundle/Contents/Resources/System.plist, which takes up a whopping 1.1Mb of space on disk as an unadulterated XML file, and piped it through the plutil as above. The resulting file came down to 919K; a saving, but not a noticable one. In fact, the reason for this poor ratio is that the majority of the entries in this file are Strings, and these aren't compressed at all by the plutil binary format. In fact, quite a lot of those Strings are repetitive as well, being as this file lists all the locations that backupd is (or isn't) supposed to back up.

As a test, I piped the original, uncompressed file, through gzip -9, and it resulted in a 105K file. That's almost the size of the saving that the binary1 format came up with. Now, load-time of the plist might be a valid factor to take into consideration (and it is quite possible that the binary format helps here) but consider that the slowest part in a computer system - particularly one with more than one core - is the disk. Loading a 105K file off disk is almost certainly faster than a 919K file, to the extent that you could do whatever you wanted in that time with compression or decompression (and still not have to do any work at the other end). For smaller files (those measured in single or tens of K) the difference might not be noticeable, but it's certainly a candidate for testing out to see what is faster/slower for loading.

The interesting thing is then the performance on more constrained devices, like the iPhone. Being able to shrink an installed file size down certainly helps reduce the delivery; but what about the runtime characteristics, not to mention, ease of loading? Stay tuned to find out.