Partager via

JSON Service Speed

  • Article

I've been playing with the DataContractJsonSerializer that comes with Orcas recently to produce some JSON-based services. DataContractJsonSerializer works just like any other XmlObjectSerializer, except of course that the serialization output looks nothing like XML when written out.

 {"content1":"this is content","content2":"this is more content","version":1}

If you attempt to push the serialized output through an XML reader or writer and examine it though, that works too through some simple but seemingly magical transformations that happen behind the scenes.

 <root type="object">
 <content1>this is content</content1>
 <content2>this is more content</content2>
 <version type="number">1</version>
</root>

This transformation trick is one that we've used elsewhere as well to give the appearance of a consistent and highly-structured set of data formats while not actually incurring the costs of that structure.

That led me to start trying to observe when the simpler structure of JSON actually provides a performance advantage over the standard DataContractSerializer. I've found that while JSON wins in terms of size, it doesn't always win in terms of serialization speed. Here were the observations that I made.

DataContractJsonSerializer tended to be faster for small and simple workloads. When the number of types was small and the types didn't have very many members, DataContractJsonSerializer could beat DataContractSerializer by 25%. This was most often true when the bulk of the object data was string content. On the other hand, DataContractSerializer caught up and then started winning as the types got more complicated. I also noticed that there were some primitive types, such as floating-point numbers, where DataContractSerializer always had a significant advantage. DataContractSerializer could turn a 25% loss into a 25% win just by changing several of the fields of a small type to doubles.

This shows that performance is a very hard thing to predict without taking measurements. I would have expected DataContractJsonSerializer to consistently win given the simpler and smaller output format but I was able to find several data contracts taken from popular services for which that wasn't true.

Next time: Timeout Error Messages

Comments

  • Anonymous
    June 30, 2008
    What does the InactivityTimeout on a secure channel do? The inactivity timeout on a message security

  • Anonymous
    June 30, 2008
    How do you explain that Json serialization which is simpler, e.g.: a) needs less memory, b) needs less logic, looses to DataContractSerializer in some cases (as you said) in terms of speed? Also it's not very obvious, why would serialization of floating point values in Json-mode be slower than using DataContractSerializer? Something must be wrong with implementation.

  • Anonymous
    June 30, 2008
    Hi Alexey, It looks like the Json serializer spends more time manipulating character buffers than is required by the Xml approach.  This is probably a tradeoff for some other scenario where the character buffers make Json faster than Xml. Json is a bit simpler format than Xml, but any serialization implementation is going to have complexity.  That's what makes it hard to predict performance through intuition.