JSON versus PLIST, the Ultimate Showdown

Communicating with web services you have to decide on a way to transport the date back and forth. Recently – with the help of the popular Twitter-API – JSON seems to have come ahead in the race. Other contenders are property lists and XML. Property Lists (PLISTs) are available in XML-Text and a binary (“old”) format and are widely supported in the Apple APIs which makes them a joy to work with.

JSON files on the other hand are easy to be generated server-side as they are basically just concatenated text, much less verbose than pure XML. The binary alternative might also be a contender when it comes to performance in transmission and parsing, provided some component is installed on the server to generate them.

In this blog article we are trying to answer the question once and for all what you should use in your own apps.

Martin Brugger from Austrian iOS development company BytePoets spent a lot of time researching the hard facts for us, so that we have a solid base for our analysis. In part this work is based on what Sam Soffes previously published on the performance of a variety of JSON benchmarks. He created a new GitHub project for his benchmarks which are using all the latest version of all JSON toolkits from where you can check out the code for yourself.

These experiments specifically excluded raw XML parsing because the NSXMLParser that comes with iOS is using the sequential SAX method and thus the results cannot be easily compared to JSON and PLIST which take in text and output NSDictionary or NSArray objects. Most of the data types in JSON and all of the ones in PLISTs map to typed Objective-C objects, in contrast to XML where you don’t have such a built in schema. Thus pure XML might be more flexible, but at the same time you have to jump through hoops to get strong typing. It’s a non-starter in today’s race.

So the contestors in our race where:

• YAJL
• JSONKit
• TouchJSON
• JSON Framework
• Apple’s JSON Framework (private)
• Property List (XML)
• Property List (Binary)

One interesting thing that Soffes had uncovered was that Apple indeed has their own highly performant private API for parsing JSON. Sam reconstructed the necessary headers and so it’s another interesting contender to see here, even though we are not allowed to use the JSON.framework in our app store apps. Pity, it’s quite fast.

The amazing race

To get even more relevant data Brugger benchmarked the serialization and deserialization of an array and a dictionary of 1000 entries each) and the standard Twitter JSON. Since the latter cannot be mappted into property lists, this test was excluded for PLISTs.

Here are the writing results, shorter bars are better.

As you can see there is a wide variety between the various toolkits. Arrays, Dictionaries and Twitter’s JSON take varying amounts of time to process. We immediately see the winner: JSONKit, which was just recently updated to version 1.4. Second place goes to property lists, where – curiously – there is almost no difference between the binary and XML formats. Then there is the JSON Framework on the third spot, winning over the private Apple API ever so slightly.

I get the feeling that the low level optimization work that’s been put into JSONKit as well as being carried out by smart Apple engineers is responsible for this result.

Let’s have a look at the reading performance. This is probably the more important one of both benchmarks since most of the data on your mobile device will be received and consumed. Here the verdict is a little more complex than just stating places. Just as with the writing benchmarks arrays are generally quicker to process. This part is again clearly won by JSONKit, closely followed by binary PLIST. Third place is split between YaJL and Apple JSON.

If the consumed data is a big dictionary the clear winner is the binary property list, followed by JSONKit and Apple JSON. YAJL and XML PLIST share the forth place.

When it comes to “real life” scenarios – like parsing the Twitter JSON – property lists cannot compete unfortunately, so here’s another clear win for JSONKit. This is by a wide margin as the second YAJL and the third Apple JSON are orders of magnitude slower.

Does size matter?

Now another question we set out to answer revolves around the time it takes for JSON or PLIST data to be transferred to the client. This is a function of the size, the smaller it is even without compression, the faster it has travelled over the pipe.

My hunch was that binary PLISTs would be way smaller then everything else, but I was proven wrong as you can see from the following chart:

The NSArray is a third larger expressed as XML PLIST than as JSON, the NSDictionary is even twice as large. The binary PLIST is about the same, so much less of a dramatic difference than I had expected.

Conclusion

In terms of transfer speed any plain-text format like XML or XML Plist loses against the compactness of JSON or binary PLISTs. But as stated earlier the difference between BPLIST and JSON can be disregarded because there almost is none.

In all tests JSONKit was the clear winner or came pretty close to it. It really depends on the specifics of your own project whether you would best use this or Apple’s binary PLIST format. If you are coding multi-platform then it would probably be smarter to go for JSON because the binary PLIST format is not widely used on any other platforms than iOS or OSX. In contrast if you can afford the luxury of only targeting Apple platforms then binary PLIST is just as good a choice, provided you can install the components necessary on your server to be able to output it there.

For all other intents and purposes you can think of JSONKit and binary property lists as identical in transfer and processing speeds. Thanks to the amazing tuning that went into both.

Categories: Q&A