Comparing the Performance of .NET Serializers

Comparing the Performance of .NET Serializers

Rate This
  • Comments 11

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.

Leave a Comment
  • Please add 2 and 5 and type the answer here:
  • Post
  • 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.

  • 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.

  • Looks like BinaryDataContractSerializer was the overall best performer to me...

  • 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.

  • Can you share your test code please?

  • 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.

  • eh, I just realized that higher means faster not slower!

    Nevermind these results are actually close to what I got :)

  • 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 serializers

  • 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 Ravi

  • Nice article, just be aware of the following (potential) bug/complication: connect.microsoft.com/.../xmlbinaryreader-not-able-to-read-from-fixed-size-buffer

  • That's a great article, thank you very much, helped a lot!

Page 1 of 1 (11 items)