How does JSON compare to XML in terms of file size and serialisation/deserialisation time?

I have an application that 开发者_如何学运维performs a little slow over the internet due to bandwidth reasons. I have enabled GZip which has improved download time by a significant amout, but I was also considering whether or not I could switch from XML to JSON in order to squeeze out that last bit of performance. Would using JSON make the message size significantly smaller, or just somewhat smaller? Let's say we're talking about 250kB of XML data (which compresses to 30kB).

---

In terms of object serialization, JSON will generally be more compact (even when compressed). For Example:

I serialized the same instance of an object into both XML and JSON and got the following:

JSON

{
    "Account": "2222",
    "Login": "124235",
    "SalesId": null,
    "CustomerReference": "9652358474",
    "Status": null,
    "DropShip": 0,
    "PromoCode": null,
    "Notes": "For the truck",
    "Errors": null,
    "ReferenceId": null,
    "PaymentMethod": "CKPhone",
    "CheckPayment": {
        "Name": "Simon Riggs",
        "CompanyName": "Darth Inc",
        "AccountNumber": "565555555",
        "RoutingNumber": "222224455116",
        "CheckNumber": "32",
        "Address": {
            "Attention": null,
            "Street1": "555 W Portebello Rd",
            "Street2": null,
            "City": "London",
            "State": "Texas",
            "Zipcode": "45217",
            "Country": null,
            "ReferenceId": null,
            "GetAxType": 2
        },
        "ReferenceId": null,
        "GetAxType": 2
    },
    "CreditCardPayment": {
        "Name": "Simon Riggs",
        "CardNumber": "1111222233334444",
        "Cvv2": "546",
        "Month": 10,
        "Year": 2018,
        "Address": {
            "Attention": null,
            "Street1": "555 W Portebello Rd",
            "Street2": null,
            "City": "London",
            "State": "Texas",
            "Zipcode": "45217",
            "Country": null,
            "ReferenceId": null,
            "GetAxType": 2
        },
        "ReferenceId": "0",
        "GetAxType": 2
    },
    "ShippingAddress": {
        "Attention": "Simon Riggs",
        "Street1": "555 W Portebello Rd",
        "Street2": null,
        "City": "London",
        "State": "Texas",
        "Zipcode": "45217",
        "Country": null,
        "ReferenceId": null,
        "GetAxType": 2
    },
    "Totals": {
        "SubTotal": 25.0,
        "TotalTax": 5.0,
        "ShippingTotal": 10.0,
        "ShippingTax": 1.5,
        "GrandTotal": 35.0
    },
    "Lines": [{
        "SKU": "1442-4521",
        "LineNum": 0.0,
        "Qty": 2.0,
        "Price": 72.95,
        "ShippingClass": "Ground",
        "ReferenceId": null,
        "GetAxType": 2
    },
    {
        "SKU": "1212-5549",
        "LineNum": 0.0,
        "Qty": 1.0,
        "Price": 31.15,
        "ShippingClass": "Ground",
        "ReferenceId": null,
        "GetAxType": 2
    }],
    "GetAxType": 2
}

XML

<?xml version="1.0" encoding="utf-16"?>
<SalesOrder xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Account>2222</Account>
  <Login>124235</Login>
  <CustomerReference>9652358474</CustomerReference>
  <DropShip>0</DropShip>
  <Notes>For the truck</Notes>
  <PaymentMethod>CKPhone</PaymentMethod>
  <CheckPayment>
    <Name>Simon Riggs</Name>
    <CompanyName>Darth Inc</CompanyName>
    <AccountNumber>565555555</AccountNumber>
    <RoutingNumber>222224455116</RoutingNumber>
    <CheckNumber>32</CheckNumber>
    <Address>
      <Street1>555 W Portebello Rd</Street1>
      <City>London</City>
      <State>Texas</State>
      <Zipcode>45217</Zipcode>
    </Address>
  </CheckPayment>
  <CreditCardPayment>
    <Name>Simon Riggs</Name>
    <CardNumber>1111222233334444</CardNumber>
    <Cvv2>546</Cvv2>
    <Month>10</Month>
    <Year>2018</Year>
    <Address>
      <Street1>555 W Portebello Rd</Street1>
      <City>London</City>
      <State>Texas</State>
      <Zipcode>45217</Zipcode>
    </Address>
    <ReferenceId>0</ReferenceId>
  </CreditCardPayment>
  <ShippingAddress>
    <Attention>Simon Riggs</Attention>
    <Street1>555 W Portebello Rd</Street1>
    <City>London</City>
    <State>Texas</State>
    <Zipcode>45217</Zipcode>
  </ShippingAddress>
  <Totals>
    <SubTotal>25</SubTotal>
    <TotalTax>5</TotalTax>
    <ShippingTotal>10</ShippingTotal>
    <ShippingTax>1.5</ShippingTax>
    <GrandTotal>35</GrandTotal>
  </Totals>
  <Lines>
    <SalesLine>
      <SKU>1442-4521</SKU>
      <LineNum>0</LineNum>
      <Qty>2</Qty>
      <Price>72.95</Price>
      <ShippingClass>Ground</ShippingClass>
    </SalesLine>
    <SalesLine>
      <SKU>1212-5549</SKU>
      <LineNum>0</LineNum>
      <Qty>1</Qty>
      <Price>31.15</Price>
      <ShippingClass>Ground</ShippingClass>
    </SalesLine>
  </Lines>
</SalesOrder>

When encoded in ASCII, the JSON is 1422 bytes while the XML is 1954 bytes. After compressing them using a GZipStream, the difference is smaller but still pretty clear. The JSON compresses down to 524 bytes while the XML compresses down to 695 bytes.

Serialization/deserialization time will vary by implementation (and hardware of course) but I serialized and deserialized the above JSON and XML 100,000 times in a loop and got the total accumulative times:

JSON Serialization: 5258 ms, XML Serialization: 3266 ms

JSON Deserialization: 9582 ms, XML Deserialization: 4604 ms

So XML serializes and deserializes faster using the libraries I'm using (see below), but with averages measuring in the hundredths of milliseconds, I'd say network bandwidth and transfer time is more consequential.

(Note: I did this in C# using Microsoft's System.Xml.Serialization.XmlSerializer and JSON.Net's Newtonsoft.Json.JsonConvert classes)

---

Not an answer, but rather a suggestion to examine your assumptions.

How is JSON smaller?

JSON:

"person":{"firstname":"Fred", 
          "lastname":"Flintstone",  
          "age":38, 
          "spouse":"Wilma" }

XML:

<person firstname='Fred' 
        lastname='Flintstone' 
        age='38' 
        spouse='Wilma'/>

I just don't see how, in general, a JSON expression is going to be 30% smaller than "equivalent" XML. Even as you ramp up the complexity of these things, with nested structures and arrays, it's not going to be a 30% difference. It's approximately equivalent, with json earning an advantage because the end tag of a nested structure is a } , while XML earns an advantage because it need not quote field names.

If you forced me to use XML elements, like this:

<person>
   <firstname>Fred<firstname>
   <lastname>Flintstone<lastname>
   <age>38</age>
   <spouse>Wilma</spouse>
</person>

...sure, the resulting XML is larger than the prior JSON. But that seems like cheating.

---

Now it may be that the way you format your XML currently uses elements for everything, and that there's an opportunity to shrink the payload accordingly. But that doesn't necessarily imply JSON. If you've got tools and libraries that handle XML, you can keep XML and shrink.

---

actually this is harder to answer then it seems,

several years ago json was 'faster' but the differences have become finer between the two.

what I've observed is;

• xml compresses better with gzip then json .. time saved in download can offset other components
• xml parsing/querying in raw js is roughly equiv with json
• xml parsing/querying in jquery is much slower ... I won't begrudge jquery developers to focus on json

overall, tech that speeds up modern browsers also applies to xml processing as well.

generally, whenever I hear json touted as a 'lowfat' alternative to XML I wonder if its not some subliminal obsession with weight issues ... thats on my pessimistic days;

basically the rule of thumb I follow is

markup good for documents json good for data

and move on ... nothing to see here

---

The best way to answer this is to test it yourself, since compression is involved. You also neatly avoid the XML vs JSON holy war by having an objective answer!

Since it's just a test and doesn't really need to work, you could just write up an xml->json converter in javascript that walked the XML DOM tree and copied it into a nested array/object structure then passed it to JSON.stringify(). The only tricky bit would be deciding what becomes an array and what becomes an object.

Find a representative sample (or a few) of the data being sent, convert it to JSON with your tool, gzip it and the original XML and compare sizes.

Note: I looked around for an online XML->JSON converter and they were all terrible--copius whitespace outside of quotes (illegal in JSON, alters size) and unquoted key names (ditto). Don't use them for your test or you'll get bad data.

---

Generally speaking, JSON is much faster and smaller than the equivalent XML. XML is richer in that you can store metadata (attributes) and content separately, but the same can be achieved in JSON with appropriate structuring conventions.

---

Yes JSON would be about 30% faster there are fewer characters going over the line and its very quick to parse.

Ypu could also take a look at "YAML" which sends an absolute mininmum of metadata in the message.

---

<person firstname='Fred' 
        lastname='Flintstone' 
        age='38' 
        spouse='Wilma'/>

"person":{"firstname":"Fred", 
          "lastname":"Flintstone",  
          "age":38, 
          "spouse":"Wilma" }

XML: 80 chars

JSON: 92 chars.

XML is the 13% slimmer winner, who would have thought for all the bogus claims?

[Example taken from Cheeso above. Note that carriage return types change the size but equally for both. Without any returns in either, the ratio is XML: 74, JSON: 86, a 14% difference]

Someone claimed in this discussion that "using attributes for content is cheating" (citing [this][1]).

1) Pray tell how well formed XML is 'cheating'? If it doesn't cheat the (very long) spec, then let's please get over it. Valid is valid.

2) In that case an ASP.NET web.config is 'cheating', among a thousand other big-dog examples.

<forms loginUrl="~/Home/Login" 
       defaultUrl="~/Home" 
       timeout="2880" 
       requireSSL="false" 
       slidingExpiration="true" />

To be fair, there are those who tend to have a bloated-XML mentality in how they form the XML.

But it should not be said that the 13% slimmer XML variety is not just as valid. And thus it even beats JSON (in size).

[1]: http://www.ibm.com/developerworks/xml/library/x-eleatt/index.html [2004 article, mind you]