Comparing the Performance of .NET Serializers
The .NET framework comes with a variety of different serializers. Hopefully, my overview of these serializers will have provided some insight into the differences between them and the various advantages and disadvantages of using different serializers. But there are not only great differences in functionality between the serializers, but there are also vast differences in performance. This is an attempt to provide a rough idea of how serializers stack up against each other as far as performance (speed) is concerned and as far as the size of the serialized instances.
Disclaimer
Serialization performance can vary a lot between different machines, and depends heavily on the object being serialized, the serializer features being used, and the stream or writer to which the serialized instance is being written to. This is only meant to give you a glimpse into how fast or slow serializers might be. If you’re concerned with serialization performance in your scenarios, the best thing you can do is run your own performance tests with the types and functionality you care about.
Setup
I decided to serialize out and deserialize the following object:
object o = new Library()
{
Name = "Library Of Congress",
Books = new List<Book>() { new Book() { Author = new Person(){ FirstName = "Barack", LastName = "Obama"}, Title = "Dreams from My Father: A Story of Race and Inheritance", Year = 1995},
new Book() { Author = new Person(){ FirstName = "Lewis", LastName = "Caroll"}, Title = "Alice's Adventures in Wonderland", Year = 1865},
new Book() { Author = new Person(){ FirstName = "Kurt", LastName = "Vonnegut"}, Title = "Welcome to the Monkey House", Year = 1968},
new Book() { Author = new Person(){ FirstName = "Orson", MiddleName = "Scott", LastName = "Card"}, Title = "Ender's Game", Year = 1985}}
};
Using each of the serializers. This object contains lists, strings, ints, and several classes. It is meant to represent a “typical” object. I used a MemoryStream to write to and read from for all five serializers, and then used XmlDictionaryWriter/Reader.CreateBinaryWriter/Reader to create binary writers for testing the Binary XML performance for DataContractSerializer, NetDataContractSerializer, and XmlSerializer. All of these serializers were used without any particular switches, and no customizations were made to the format of the serialized string. Only parameterless DataContract, DataMember, and Serializable attributes were added. Serialization and deserialization throughputs were measured directly, while roundtrip throughput was calculated using the formula: roundtrip throughput = 1/((1/serialization throughput) + (1/deserialization throughput)).
Results
There are several things we can infer from the data:
· The serializers seem to perform in roughly the following order: DataContractSerializer, XmlSerializer, DataContractJsonSerializer, NetDataContractSerializer, BinaryFormatter
· Using binary XML writers and readers seems to improve speed by ~5-40% and decreases message size by ~30-50% depending on the serializer
· DataContractJsonSerializer produces the smallest serialized instances, followed by DataContractSerializer, BinaryFormatter, XmlSerializer, and NetDataContractSerializer
Overall, DataContractSerializer comes out as the winner of this perf-off with the fastest speed and the second smallest serialized instance size.
Comments
Anonymous
August 17, 2009
Looking at the graphs it doesn't look to me that DataContractSerializer. It is DataContractJsonSerializer which is second smallest and fastest is BinaryFormatter. Any typo in your "Overall...." statement? Thanks.Anonymous
August 17, 2009
The first two graphs measure throughput (operations per second) so bigger bars offer better performance. BinaryFormatter was the slowest serializer in these tests. The last graph measures size on the wire. In that case, smaller bars offer better compression of the data.Anonymous
March 10, 2010
Looks like BinaryDataContractSerializer was the overall best performer to me...Anonymous
March 12, 2010
Just to clarify, BinaryDataContractSerializer isn't a separate serializer. It's just DataContractSerializer writing to a binary XmlDictionaryWriter. The XmlWriter's performance matters in that case.Anonymous
April 16, 2010
Can you share your test code please?Anonymous
January 23, 2011
Yeah I didn't get the same results in my benchmarks - the results and source code of which you can see here: www.servicestack.net/.../NorthwindDatabaseRowsSerialization.100000-times.2010-08-17.html I would add protobuf-net to your list so you can get a good baseline to compare it to. Also it makes sense to remove the first iteration as most serializers set up caching on the first iteration which heavily skews results for small iterations. So excluding it would be more representative of real-world performance you would expect if you're hosting in any long running program, i.e. IIS/ASP.NET/Windows Service/etc.Anonymous
January 23, 2011
eh, I just realized that higher means faster not slower! Nevermind these results are actually close to what I got :)Anonymous
July 30, 2013
Hi all, I tried to work serialization with DataContractSerializer in our application, the throughput of dc is not better compared with Xml Serializer. My code is : private static volatile NetDataContractSerializer dataContractSerializer; if (dataContractSerializer == null) { lock (syncRoot) { dataContractSerializer = new NetDataContractSerializer(); } } using (MemoryStream memoryStream = new MemoryStream()) { dataContractSerializer.WriteObject(memoryStream, this); } Please suggest how to improve the performance of dc over xml serializersAnonymous
July 30, 2013
in the below code, i am using data contract serializer in my wcf application, but when i need full control over my XML attributes i implemented IXmlSerializer with data contract serializer. That time my application performance got decreased. Code: [DataContract] public partial class SearchResponseNavigator : IXmlSerializable { #region IXmlSerializable Members public System.Xml.Schema.XmlSchema GetSchema() { return null; } public void ReadXml(System.Xml.XmlReader reader) { //implement if remote callers are going to pass your object in } public void WriteXml(System.Xml.XmlWriter writer) { if (!string.IsNullOrEmpty(Displayname)) writer.WriteAttributeString("displayname", Displayname.ToString()); if (!string.IsNullOrEmpty(Navigatorname)) writer.WriteAttributeString("navigatorname", Navigatorname.ToString()); if (!string.IsNullOrEmpty(Scopefieldname)) writer.WriteAttributeString("scopefieldname", Scopefieldname.ToString()); if (!string.IsNullOrEmpty(Entropy)) writer.WriteAttributeString("entropy", Entropy.ToString()); if (Modifiers != null) { writer.WriteStartElement("modifiers"); foreach (SearchResponseNavigatorModifier modifier in Modifiers.Modifier) { writer.WriteStartElement("modifier"); writer.WriteElementString("name", modifier.Name); writer.WriteElementString("value", modifier.Value); writer.WriteElementString("count", modifier.Count); writer.WriteEndElement(); } writer.WriteEndElement(); } } please advise on the above. Regards, Sriram RaviAnonymous
December 09, 2013
Nice article, just be aware of the following (potential) bug/complication: connect.microsoft.com/.../xmlbinaryreader-not-able-to-read-from-fixed-size-bufferAnonymous
February 05, 2014
That's a great article, thank you very much, helped a lot!