Skip to content
[shareaholic app="share_buttons" id="14657658"]
Share this..


2010 March 27
tags: , ,
by Eddie

I recently read an article on Linux Magazine that suggested JSON is a better tool for data transfer than XML on Android phones.  So I decided to try switching some of QueueMan’s queue retrieves over to JSON.  Eliminating the verbose tags may be much quicker over wireless airwaves.

The choir I tackled was to compare the performance of XML and JSON by downloading the user’s recommendations from the Netflix API. To make testing quick I would make a call to both XML and JSON classes in each loop, and repeat 10-30 times for each sample point.  The sample points were 1,5,10,15,25,50, and 64 discs. (64 being the current # of recommendations Netflix is offering me)

I used org.xml.sax, and org.json. JSON* as the libraries for my parsing.

Why JSON is thought to be superior to XML

So the thought, as I have seen and heard it is as follows:

JSON’s lightweight payload allows for reduced bandwidth needs and faster transfers.

That is particularly attractive for mobile devices.

What my Testing Revealed about XML vs JSON

You can see from the 108 samples above that in the 1-5 disc range that JSON indeed performed a bit quicker than XML. However the numbers quickly turned, and JSON grew exponentially slower as the disc count increased.  XML’s time grew much slower.

Why XML is a better Performer

The argument that JSON’s has a lighter data definition structure is true, but only by 50%.   And the structure for 5 discs is less than 1% of the total character payload  (0.8% in JSONs case, assuming an average label of 12 characters, not counting all the commas, parentheses, and escape characters needed).  And this drops as the numbers increase.  So if you’re just passing a “tag_names” with payloads like “8974” than JSON would be much lighter.  Once you start passing text that far exceeds your tag lengths, than JSON loses its edge.

Size Matters

{ "average_tag" :  {
"term1": "it's all about the data",
"term2": "and the amount of information",
"term3": "you need to transport"

<term1>"it's all about the data</term1>
<term2>and the amount of information</term2>
<term3>you need to transport</term3>

So although the payload is just slightly lighter,  it has one major trade-off.  XML is a parse-once-and-you’re-done deal. The entire XML file is walked once by Sax, and you just build a neat little Object as you go.  With JSON you rely on setting objects to represent the structure of the file and pull pieces using their index.   I suspect the JSON parsers walk though the string numerous times. (hence the requirement for a string, and not an input stream like Sax.)

So, as far as QueueMan and I are concerned, we’ll stick with XML.

17 Responses leave one →
  1. Dylan Andersen permalink
    April 2, 2010

    Edward, gave you a nice write-up on Android and .. go check the front page. I hope you continue your hard work on the application and check out the review I wrote!

  2. Hans permalink
    July 24, 2010

    You’re JSON code is not very efficient (also it is invalid), this would be much better:
    {“average_tag”: [“it’s all about the data”, “and the amount of information”, “you need to transport”]}

    And actually in this cases there is no need for average_tag at all, so this would be the best code:
    [“it’s all about the data”, “and the amount of information”, “you need to transport”]

  3. Eddie permalink*
    July 25, 2010

    I, like most consumers of a web service have very little control of the format. It’s structure and tags are determined by the this case n netflix.

  4. Me, myself and I permalink
    August 26, 2010

    To some extent you’re comparing apples with pears. Aside from google’s json.simple I don’t know of any SAX-like parser for JSON. If you want to do a fair comparison, use a DOM-parser for XML instead of a SAX parser. SAX parsers are way more economical in terms of processor cycles and memory, since they leave it to the caller to build a DOM tree, if required.

    After having worked with both, I can tell you what I’ve found out: the client and the server ends must be profiled separately, what technology is used on each end matters a lot, but in general, all other things being equal, XML is up to one order of magnitude slower to process than JSON, especially in web applications, where you have little choice over the encoder/decoder used on the client side – it’s usually what the browser provides. This becomes even more apparent as the size of the JSON/XML grows. Also, generating/consuming JSON on .Net end seems more difficult and more complex than on a Java end – there aren’t that many convenient JSON libs to use with .Net, customers are often reluctant to install a 3rd party library on their servers, and the solution provided by MS is awkward to use and slow. I have seen little JSON or XML communication via PHP, but it seems it’s reasonably fast, and faster than the .Net lib provided by MS’s Ajax toolkit for ASP.Net.

    Anyway, this is all based on informal experiences I had, so take it with at least a grain of salt.

  5. Eddie permalink*
    September 20, 2010

    That’s true, and yet to some extent the fact remains, for large data files the xml format and available means to process it (SAX) proved to be faster. The lack of SAX like parsers for JSON is not a handicap against XML, it is a win!

    …on the MS side all i will say is ‘no comment’. I prefer solutions well supported by the community.. and not tied to large development firms.

    Thanks for the feedback, please continue to keep me on track!

  6. SalmanAbbas007 permalink
    November 15, 2010

    Naah XML sucks sucks sucks! Uselss tags eh?

    JSON is teh Best for Web!!

  7. Cowtowncoder permalink
    January 9, 2011

    As already mentioned, org.json’s package is primitive and obsolete; no one should be using it on Java. For incremental parsing (like SAX or Stax for XML) you also need not use json-simple, as Jackson (; see [] for tutorial) also has incremental/streaming parsing, and it is much faster than any Java XML parser. But most developers use data binding (think of JAXB for XML), which is both fast and convenient.

    So for Java you may want to upgrade to Jackson and see how speed goes up by factor of 3x – 5x.

  8. Joe permalink
    February 27, 2011

    I suggest the Google GSON library which is also quite simple to use to convert JSON into Java objects for Android. By comparison, parsing these is much easier than the XML parsing examples I’ve seen in Android.

    Also, in PHP and Java, kicking out a JSON serialized object is a trivial one liner. For example, in PHP: echo json_enocode(my_obj); is all you need. Google has JSON libraries for MS too, but most things are more painful to do in the MS world while they are one liners in open source land.

    Also, I assume you meant “chore”, not “choir” in the second paragraph. Thanks for the article.

  9. Eddie permalink*
    February 28, 2011

    @Joe, thanks for the feedback.

    Yes, I did mean chore. I find my spelling getting worst the further I get from grammar school. :/

    Anyway, I’ll have to look into GSON, sounds very interesting. Just a note to readers – google-gson does not appear to be sponsored, endorsed or authored by Google.

    And I completely agree that JSON in general is easier to marshal then xml in most languages. And in a lot of cases the trade off of ease of coding can outweigh the small performance differences. My main intention for this article is that for large datasets the extra effort of coding a SAX parser provides noticeable performance gains over query calls against a JSON stream.

  10. Cthulhu permalink
    June 2, 2011

    I personally believe neither JSON nor XML are good formats, or at least not how they’re currently transmitted over the internet. Both formats need to ‘repeat’ their tag names or identifiers – so for each ‘term’ in your document, you get the overhead of writing out the ‘term’ begin/end tag in XML and the various syntax characters for JSON.

    The W3C’s new EXI standard ( looks to be very promising in this area. It has a built-in compression algorithm and a bunch of other optimizations that dramatically reduce both the size of the data transmitted and the processing required on both the sending and receiving side. In terms of size, data reductions between 40 and 100% are possible, and processing speed can increase to 100% to 3000%.

    I just hope some bright mind invents such a feature for JSON and both get implemented in browsers soon.

  11. Eddie permalink*
    June 3, 2011


    I was not aware of EXI, but it sounds very promising.

    Do you know of benchmarks on the performance costs to compress and decompress the payload on client/server? (100-3000% is a ambiguous number) Do you see existing parses like SAX or Pull being compliant with the new XML format?

  12. bhavya permalink
    December 10, 2011

    Can you provide me with the source code you are using to compare performance?
    Your post look really interesting, I was thinking to compare some other format for our application.

  13. January 9, 2012

    some one give me more useful links with best comparison between JSON Vs XML ?

  14. Impressed permalink
    May 27, 2013

    It took an Android developer to finally come to this conclusion! Congrats!

    I just read 15 articles & not one of them realized this… So disappointed. I think the reason so many developers are biased to JSON is because it’s typically easier to use than XML sax.

    In any case, I use compressed XML & our performance is top notch, especially with lots of text like you were saying.

Trackbacks and Pingbacks

  1. Android Programming Notes – 04 « Mike#
  2. Soru: json veya xml ile kategorileme
  3. XML vs JSON – Performance Tip | Edward A. Webb (.com) | xml話題ポータル.com

Leave a Reply

Note: You can use basic XHTML in your comments. Your email address will never be published.

Subscribe to this comment feed via RSS