Sep 302012
 September 30, 2012  Posted by at 1:02 pm Not So Stupid Questions  Add comments

[To celebrate my first year of programming I will ask a ‘stupid’ questions daily on my blog for a year, to make sure I learn at least 365 new things during my second year as a developer]

Serializing and desereliazing, from a performance perspective - what is the recommendation?

Serializing and desereliazing, from a performance perspective - what is the recommendation?

I’m obsessing with performance.. don’t I? 😉

Again a fresh debate. Working on a new project I’ve had the pleasure of teaming up with new developers and also new discussions. The latest one was regarding serialization and performance in C#, more specific Windows Store Apps. I was showing an example of the frustrating process of serializing and deserializing in WinRT and he noticed that had had chosen to use XmlSerializer class and commented on that.
The thing is, that when I first created an example of serialization in WinRT I had used the DataContractSerializor and had gotten some comments on the MSDN forum that it wasn’t the recommended way out of a performance perspective. And sure enough, MSDN says:

From a performance perspective, we recommend using the XmlSerializer class. The XmlSerializer has the lowest serialization and deserialization times, and maintains a low memory footprint. The XmlSerializer has few dependencies on the .NET framework; this means that compared with the other serialization technologies, fewer modules need to be loaded into your app to use the XmlSerializer.

My colleague was quick to google up some performance comparisons but the numbers varied greatly, and some of the articles were rather ‘old’. But I agree with the input, as I also thought that DataContractSerializer While it isn’t the fastest it was faster than XmlSerializer. But honestly, I can’t even remember where I had that information from. I haven’t got the time to do some performance tests right now with DevReach next week I’m a bit stressed out, but I definitive will do and post on the blog. SO as for now I’ll just go with the MSDN recommendation- but please share if you have any recent performance comparisons!

  4 Responses to “Stupid Question 55: What is the best serialization class to use from a performance perspective?”

  1. I’ve recently dropped XmlSerializer in favor of Newsoft.Json as it’s must faster and lightweight than XmlSerializer. Yet it gives me the flexibility of loose-versioning (adding and removing properties based on my daily mood). I’ve never liked XmlSerializer, it doesn’t support Dictionary serialization (

  2. […] Stupid Question 55: What is the best serialization class to use from a performance perspective? (Iris Classon) […]

  3. First you must ask yourself two questions, “Are the sender and receiver similar platforms?” and “Do I care if it’s readable by humans?” If the answers are “Yes” and “No” respectively, then you’re probably best off with BinarySerialization — it’s the fastest with the smallest output.

    If the answers are “No” or “Yes” respectively, then you’ll need some form of text serialization — generally as either XML or JSON. JSON gives somewhat smaller output. XML gives slightly more flexibility, but only extreme cases can’t be presented equally well as JSON. Processing times should be roughly equal. (i.e, there’s no technical reason why one should take longer than the other — it comes down to quality of implementation and optimizations)

    The differences between XMlSerializer and DataContractSerialize are even more trite, and are given here:

  4. I wrote a blog post that explains why the XML serializer can be slow and how ultimately, XML, SOAP, and binary serialization are all about the same – performance-wise:

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>



What is 5 + 6 ?
Please leave these two fields as-is:
IMPORTANT! To be able to proceed, you need to solve the following simple math (so we know that you are a human) :-)