Performance oriented Xml and JSON serialization in .NET

November 16, 2011 CSharp, Visual Studio, WCF , , , ,

Microsoft .NET framework provides multiple out-of-the-box data serializers for data transformations.  The most famous one used since .NET 1.0 version is XmlSerializer, while one that has got more famous since .NET 3.0 framework is DataContractSerializer.   But they are not the only two serializers the framework offers.  So in this essay, let’s see the different serializers .NET framework offers and how they are different from each other.  So here’s the list of serializers

  • XmlSerializer: The most commonly used xml serializer
  • JavaScriptSerializer:  Introduced in ASP.NET Ajax Extensions in .NET 2.0, and now marked as obsolete, primarily provided JSON serializer
  • DataContractSerializer: Introduced in .NET 3.0 with Windows Communication Foundation (WCF), this is default serializer in WCF.
  • NetDataContractSerializer: A not-too-famous serializer that includes CLR type information in serialized xml which DataContractSerializer does not.
  • DataContractJsonSerializer:  Introduced in .NET 3.5, this class is handy in generating JSON output of an entity

Next, let’s define a class Employee and implement a serializer class and try out XmlSerializer, DataContractSerializer, NetDataContractSerializer and DataContractJsonSerializer with examples.

Step 1- Defining Employee class

The structure of Employee class is different for different serializers.  So make a note that XmlSerializer requires a parameterless or a default constructor, while other serializers do not require so.  Other serialisers based on DataContractSerializer require DataContract and DataMember attribute on the class and its members, while XmlSerializer requires either a native type, or ISerizable implemented complex class (read: class)

Employee Class
  1. ///<summary>
  2. /// Employee class for all other serializers
  3. ///</summary>
  4. [DataContract]
  5. public class Employee
  6. {
  7.     [DataMember]
  8.     public string Name { get; set; }
  9.     [DataMember]
  10.     public int EmployeeId { get; set; }
  11.     ///<summary>
  12.     /// Note: Default constructor is not mandatory
  13.     ///</summary>
  14.     public Employee(string name, int employeeId)
  15.     {
  16.         this.Name = name;
  17.         this.EmployeeId = employeeId;
  18.     }
  19. }
  20. ///<summary>
  21. /// Employee class for XmlSerializer
  22. ///</summary>
  23. public class Employee
  24. {
  25.     public string Name { get; set; }
  26.     public int EmployeeId { get; set; }
  27.     ///<summary>
  28.     /// Parameter-less constructor is mandatory
  29.     ///</summary>
  30.     public Employee() { }
  31.     public Employee(string name, int employeeId)
  32.     {
  33.         this.Name = name;
  34.         this.EmployeeId = employeeId;
  35.     }
  36. }

Step 2 – Defining the Serialization Factory

To define the serialization factory, we will define an enum SerializerType, and a factory class SerializerFactory and add reference to System.Runtime.Serialization using “Add Reference” option

  1. public enum SerializerType
  2.     {
  3.         ///<summary>
  4.         /// XmlSerializer
  5.         ///</summary>
  6.         Xml,
  7.         ///<summary>
  8.         /// DataContractJsonSerializer
  9.         ///</summary>
  10.         JSON,
  11.         ///<summary>
  12.         /// DataContractSerializer
  13.         ///</summary>
  14.         WCF,
  15.         ///<summary>
  16.         /// NetDataContractSerializer
  17.         ///</summary>
  18.         CLR
  19.     }

The factory class could be plain vanilla object creation based on the enum (SerializerType) value, however creation of serialization object is heavy on performance. Hence, we would like to cache it in the memory for re-use.  So the factory class has been optimized for better performance using a Dictionary of serializers.

Serialization Factory
  1. public static class SerializerFactory
  2.     {
  3.         private static Dictionary<Type, Dictionary<SerializerType, object>> _knownObjects;
  4.         static SerializerFactory()
  5.         {
  6.             _knownObjects = new Dictionary<Type, Dictionary<SerializerType, object>>();
  7.         }
  8.         internal static ISerializer<T1> Create<T1>(SerializerType serializerType)
  9.         {
  10.             Type type = typeof(T1);
  11.             if (_knownObjects.ContainsKey(type))
  12.             {
  13.                 if (_knownObjects[type].ContainsKey(serializerType))
  14.                     return ((ISerializer<T1>)_knownObjects[type][serializerType]);
  15.             }
  16.             ISerializer<T1> returnValue = null;
  17.             switch (serializerType)
  18.             {
  19.                 case SerializerType.Xml:
  20.                     returnValue = new XmlSerializer<T1>();
  21.                     break;
  22.                 case SerializerType.JSON:
  23.                     returnValue = new JsonSerializer<T1>();
  24.                     break;
  25.                 case SerializerType.WCF:
  26.                     returnValue = new WcfSerializer<T1>();
  27.                     break;
  28.                 case SerializerType.CLR:
  29.                     returnValue = new ClrSerializer<T1>();
  30.                     break;
  31.                 default:
  32.                     throw new NotSupportedException(“Unknown serializer type”);
  33.                     break;
  34.             }
  35.             if (_knownObjects.ContainsKey(type) == false)
  36.                 _knownObjects.Add(type, new Dictionary<SerializerType, object>());
  37.             _knownObjects[type].Add(serializerType, returnValue);
  38.             return returnValue;
  39.         }
  40.     }


Step 3 – The Main Program (consuming application)

Our main program should be able to support serialization of Employee class, or a list of employee class as shown below:

Main Program
  1. class Program
  2.     {
  3.         static void Main(string[] args)
  4.         {
  5.             List<Employee> employees = new List<Employee>()
  6.             {
  7.                 new Employee(“Tim”, 1392902),
  8.                 new Employee(“Shawn”, 156902),
  9.             };
  10.             ISerializer<List<Employee>> xmlSerializer = SerializerFactory.Create<List<Employee>>(SerializerType.Xml);
  11.             string xml = xmlSerializer.Serialize(employees);
  12.             ISerializer<List<Employee>> jsonSerializer = SerializerFactory.Create<List<Employee>>(SerializerType.JSON);
  13.             string json = jsonSerializer.Serialize(employees);
  14.             ISerializer<List<Employee>> clrSerializer = SerializerFactory.Create<List<Employee>>(SerializerType.CLR);
  15.             string clr = clrSerializer.Serialize(employees);
  16.             ISerializer<List<Employee>> wcfSerializer = SerializerFactory.Create<List<Employee>>(SerializerType.WCF);
  17.             string wcf = wcfSerializer.Serialize(employees);
  18.             Console.ReadKey();
  19.         }
  20.     }


Step 4 – The Serializer implementations

To make this essay shorter and easy to comprehend, only two implementations have been mentioned here: Xml and JSON serializer.  The other two have been included in the source code.

Implementing XmlSerializer

As mentioned earlier, the Xml Serializer requires a default constructor without which the program will throw a runtime exception.

Implementation: XmlSerializer
  1. public class XmlSerializer<T> : ISerializer<T>
  2.     {
  3.         System.Xml.Serialization.XmlSerializer _xmlSerializer =
  4.             new System.Xml.Serialization.XmlSerializer(typeof(T));
  5.         public string Serialize(T value)
  6.         {
  7.             MemoryStream memoryStream = new MemoryStream();
  8.             XmlTextWriter xmlTextWriter = new XmlTextWriter(memoryStream, Encoding.UTF8);
  9.             _xmlSerializer.Serialize(xmlTextWriter, value);
  10.             memoryStream = (MemoryStream)xmlTextWriter.BaseStream;
  11.             return memoryStream.ToArray().ToStringValue();
  12.         }
  13.         public T Deserialize(string value)
  14.         {
  15.             MemoryStream memoryStream = new MemoryStream(value.ToByteArray());
  16.             XmlTextWriter xmlTextWriter = new XmlTextWriter(memoryStream, Encoding.UTF8);
  17.             return (T)_xmlSerializer.Deserialize(memoryStream);
  18.         }
  19.     }


Implementing JSON Serializer

A Json Serializer is very handy serializer specially when dealing with REST services, or JavaScript, or cross-platform messaging applications.  In recent times, JSON has gained more adoptability considering the ease to understand the serialized output and the cleanliness

Implementation:JSON Serializer
  1. public class JsonSerializer<T> : ISerializer<T>
  2.     {
  3.         DataContractJsonSerializer _jsonSerializer = new DataContractJsonSerializer(typeof(T));
  4.         public string Serialize(T value)
  5.         {
  6.             MemoryStream ms = new MemoryStream();
  7.             _jsonSerializer.WriteObject(ms, value);
  8.             string retVal = ms.ToArray().ToStringValue();
  9.             ms.Dispose();
  10.             return retVal;
  11.         }
  12.         public T Deserialize(string value)
  13.         {
  14.             MemoryStream ms = new MemoryStream(value.ToByteArray());
  15.             T obj = (T)_jsonSerializer.ReadObject(ms);
  16.             ms.Close();
  17.             ms.Dispose();
  18.             return obj;
  19.         }
  20.     }


Step 5 – Comparing the serialization results


<?xml version=”1.0″ encoding=”utf-8″?>
<ArrayOfEmployee xmlns:xsi=”” xmlns:xsd=””>

A default schema/namespace defined by is added in the root node and the collection is named as ArrayOfEmployee. The output is always a valid Xml.





There is no schema added to the serialized string and the string is more clean and readable.  Items are grouped by parenthesis { } and the collection is encapsulated within Box brackets [ ]


<ArrayOfEmployee xmlns=”” xmlns:i=””>

A default schema/namespace defined by Microsoft and is added in the root node and the collection is named as ArrayOfEmployee. The output is always a valid Xml.


<ArrayOfEmployee z:Id=”1″ z:Type=”System.Collections.Generic.List`1[[Serializers.Employee, Serializers, Version=, Culture=neutral, PublicKeyToken=null]]” z:Assembly=”0″ xmlns=”” xmlns:i=”” xmlns:z=””>
<_items z:Id=”2″ z:Size=”4″>
<Employee z:Id=”3″>
<Name z:Id=”4″>Tim</Name>
<Employee z:Id=”5″>
<Name z:Id=”6″>Shawn</Name>
<Employee i:nil=”true”/>
<Employee i:nil=”true”/>

A default schema/namespace defined by Microsoft and is added in the root node and the collection is named as ArrayOfEmployee. The output is always a valid Xml, however the Xml nodes also define CLR metadata such as Type, Size, Version, Id, etc.

[Updated] Performance benchmarks

I modified the example to add 200K employees to the collection to benchmark the performance results.  For the first time, serialization took more time as the serialization object was not cached, but for the subsequent times there was 17-44% improvement in the performance.

XmlSerializer (1): Time to executed 1142.0654 mSec
XmlSerializer (2): Time to executed 635.0364 mSec

DataContractJsonSerializer (1): Time to executed 847.0484 mSec
DataContractJsonSerializer (2): Time to executed 611.0349 mSec
CLR (1): Time to executed 2179.1246 mSec
CLR (2): Time to executed 1914.1095 mSec
DataContractSerializer (1): Time to executed 539.0308 mSec
DataContractSerializer (2): Time to executed 413.0236 mSec
What is worth noticing is the that DataContractSerializer is the fastest serializer, followed by DataContractJsonSerializer and XmlSerializer.  Unless absolutely required NetDataContractSerializer should not be used.

I hope this essay helps in understanding serializers better!

Download the source code [] from SkyDrive

Complete Guide to Lazy Loading in C#

October 23, 2011 CSharp, Visual Studio , ,

In creating performance-centric applications one has to be very cautious about how and when objects are created and destroyed.  An early creation of an object is equally dangerous as is delayed clean-up.  When an object is created before it is actually required, the object finds itself residing in a memory stack at much distant location from the place it is referenced – hence requiring more POP and PUSH statements to retrieve its value each time it is referenced.

To optimize this, C# 4.0 introduced Lazy object loading.  Lazy loading refers to creating and initializing of objects only when it is required for the first time.  That means, you can define the object whenever you wish to, but it actually gets created only when you access its method/property/function. So this essay talks about Lazy loading in C# 4.0

Until C# 3.0, you could implement lazy loading explicitly but with C# 4.0 you can just use Lazy<T> class to implement lazy loading.  It is faster, and standard approach to loading objects and is much recommended for better performance and memory optimization.

Using Lazy<T>

For this essay, we will create a Console application and experiment on a very small & simple class Database (as I don’t like using Foo for examples).  The class just has one property Name.


Getting Started
  1. class Program
  2.     {
  3.         static void Main(string[] args)
  4.         {
  5.             // Defining database
  6.             Lazy<Database> database = new Lazy<Database>();
  7.             Console.WriteLine(“Defined database object. Is database object created?”);
  8.             // Check if database object has been initialized
  9.             if (database.IsValueCreated)
  10.                 Console.WriteLine(“Database is initialized now!”);
  11.             else
  12.                 Console.WriteLine(“Database is not initialized yet!”);
  13.             // Will throw an exception.. as it does not have parameter-less constructor
  14.             Console.WriteLine(“Database: Name =” + database.Value.Name);
  15.             // Check if database object has been initialized
  16.             if (database.IsValueCreated)
  17.                 Console.WriteLine(“Database is initialized now!”);
  18.             Console.ReadKey();
  19.         }
  20.     }
  21.     public class Database
  22.     {
  23.         public string Name { get; set; }
  24.         public Database(string name)
  25.         {
  26.             Console.WriteLine(“Database object constructor called”);
  27.             Name = name;
  28.         }
  29.     }


When you execute this program it gives you the result as:

Defined database object. Is database object created?
Database is not initialized yet!

followed by an exception: The lazily-initialized type does not have a public, parameterless constructor.

Okay, let’s add a parameter-less constructor to Database class and re-run it.  The new Database class appears like:

Database class
  1. public class Database
  2.     {
  3.         public string Name { get; set; }
  4.         public Database()
  5.         {
  6.             Console.WriteLine(“Database object constructor called”);
  7.             Name = “MyName”;
  8.         }
  9.     }


The new output is:

Defined database object. Is database object created?
Database is not initialized yet!
Database object constructor called
Database: Name =MyName
Database is initialized now!


Let’s analyse this. When we defined object database (of Lazy<Database>), CLR created an object of Lazy wrapper but not the object of Database class.  When we accessed the property Name of the database object (database.Value.Name), an object of Database class was created & Database constructor was called.   But does it mean, lazy loading always requires a parameter-less constructor of the class that needs to be loaded lazily?  Well, if that is the case it is not the best fit for Business Applications.  So let’s fix that.

Initializing with delegate
  1. // For parameter-based constructor
  2.             Lazy<Database> database = new Lazy<Database>(() =>
  3.                 {
  4.                     Database internalObject = new Database(“MyNewName”);
  5.                     return internalObject;
  6.                 });


The new output is:

Defined database object. Is database object created?
Database is not initialized yet!
Database object constructor called
Database: Name =MyNewName
Database is initialized now!


Thread-safety with Lazy<T>

If you are building performance centric applications, you would definitely want to use the power of multiple processors/cores using threads.  So is Lazy<T> class thread-safe? Well yes, it’s thread-safe.  You have got multiple options for thread-safety with lazy loading

Thread safety with Lazy<T>
  1. Lazy<Database> database = new Lazy<Database>(() =>
  2.             {
  3.                 Database internalObject = new Database(“MyNewName”);
  4.                 return internalObject;
  5.             }, System.Threading.LazyThreadSafetyMode.ExecutionAndPublication);



Only single thread is responsible for initializing of the object (Lazy<T>) in a thread-safe manner.  When you are using this mode, it is preferable not to use lock in the constructor of the object used with Lazy<T> (here Database class).  This mode can cause a lot of trouble on heavy use because the possibility of deadlocks rises with each dependency between the objects.

  1. static void Main(string[] args)
  2.         {
  3.             Lazy<Database> database = new Lazy<Database>(() =>
  4.             {
  5.                 Database internalObject = new Database(“MyNewName”);
  6.                 return internalObject;
  7.             }, System.Threading.LazyThreadSafetyMode.ExecutionAndPublication);
  8.             ThreadPool.QueueUserWorkItem(new WaitCallback(ProcessDatabase), database);
  9.             ThreadPool.QueueUserWorkItem(new WaitCallback(ProcessDatabase), database);
  10.             Console.ReadKey();
  11.         }
  12.         static void ProcessDatabase(object input)
  13.         {
  14.             Lazy<Database> database = input as Lazy<Database>;
  15.             Thread.Sleep(10);
  16.             database.Value.Counter++;
  17.             Console.WriteLine(“Counter : “ + database.Value.Counter + ” at “ + DateTime.Now.ToString());
  18.         }

The output of following code is:

Database object constructor called
Counter : 1 at 23/10/2011 20:59:33
Counter : 2 at 23/10/2011 20:59:33



All threads create an instance of the object, but only the first completely initialized one is published to all threads. This reduces the amount of deadlocks that can be caused with ExecutionAndPublication.  However, in case multiple-threads can create an object and persist different values.


  1. Lazy<Database> database = new Lazy<Database>(() =>
  2.             {
  3.                 Database internalObject = new Database(“MyNewName”);
  4.                 return internalObject;
  5.             }, System.Threading.LazyThreadSafetyMode.PublicationOnly);


The output of following code is :

Database object constructor called
Database object constructor called
Counter : 1 at 23/10/2011 20:56:19
Counter : 2 at 23/10/2011 20:56:19


This is by-far the most risky mode as it is not thread-safe if the instance is accessed from multiple threads.  The behavior is undefined and should be used only if high-performance is desirable on single-thread applications


Exception Handling with Lazy<T>


Lazy<T> handles exceptions in two ways

  • For a single-threaded lazy-loading, the exception is thrown directly to the consuming class
  • For multiple-threaded lazy-loading (using ExecutionAndPublication mode), the exception during initializing the object is cached and thrown at the first access of the object.  So when the object is initialized, there won’t be any exception thrown.

For multi-threaded applications, it is preferable to handle exceptions at each thread level rather than aggregating them at the main-thread.


Final words

Lazy loading using Lazy<T> can be used in many scenario’s such as:

  • Data layer – with ADO.NET, or Entity Framework
  • Reflection – loading assemblies, types, MEF
  • Caching of objects, domain entities

But one should take care of many design related issues while using lazy loading

  • Inconsistent state of objects
  • Hiding of business requirements due to abstraction

I hope this essay helps you to understand and implement lazy loading with C# 4.0

Download the Source Code from SkyDrive

Fix: Program does not contain a static ‘Main’ method suitable for an entry point

October 18, 2011 CSharp, Visual Studio, Winform, WPF , , , ,

This does not require a detailed post and just requires a quick solution for the problem-

Understanding the problem… Why? When?

When you convert a Winform application into a WPF application –  In a Winform or a Console application, you need a static Main method that acts as an entry point to your executable.  In a WPF application, you do not require any such static class to be present at the compile time.  You need an App.xaml file that appears something like this

[sourcecode language=’xml’]


Here StartupUri represents the first/launch WPF Window or a Page and the App.xaml.cs is very short and simple

[sourcecode language=’csharp’] using System.Windows;

namespace MyWPFApplication

/// Interaction logic for App.xaml

public partial class App : Application


When you migrate a Winform application to WPF application, you can add this file explicitly to your project to get started. But when you would compile, you will find a compilation issue

Program does not contain a static ‘Main’ method suitable for an entry point

So the compiler treats App.xaml just like any other WPF page instead of a special class which we call it as ApplicationDefinition class.

What is the fix?


Check the properties of App.xaml. Change the Build Action to ApplicationDefinition and re-compile.

This also means, you can have any XAML file to be your ApplicationDefinition file.  But it is preferable to name it App.xaml since it is industry standard and adds consistency to all your projects.




Winform Tip#10: Getting File Properties

July 25, 2009 CSharp, Visual Studio, Winform , , ,

Instantiate a FileInfo object with the full path as constructor arg. Then simply call FileInfo.Extension and you will get just the extension of the file.


FileInfo finfo = new FileInfo(strFileName);

Similarly, you can get more properties

Winform Tip#9: ColorPicker

July 24, 2009 CSharp, Visual Studio, Winform , , ,

Choose a textbox over which we will test this experiment:
[sourcecode language=’csharp’] ColorDialog colorDialog1 = new ColorDialog();

//fontDialog1.ShowColor = true;

if(colorDialog1.ShowDialog() != DialogResult.Cancel )
txtMessage.ForeColor = colorDialog1.Color;
txtMessage.Text = “Test for ColorPicker”;


Another tip in this: Similar is for FontDialog. Try using it 🙂

Winform Tip#8: Clearing cache Webbrowser

July 20, 2009 CSharp, Winform , , ,

Check out:

It is indeed a good read.

Winform Tip#7:Browser within Winform

July 5, 2009 CSharp, Winform , , ,

WebBrowser control can be used inside a form to display HTML contents and listen to events such as NavigateComplete or BeforeNavigate

Use of ActiveX wrappers over old DLLs is not prefered.

Winform tip#6:DataGrid vs DataGridView

July 1, 2009 CSharp, Winform , , ,

DataGridView is an enhanced version of DataGrid.  Some of the features lacking in DataGrid are:

  1. Multiple column types
  2. Multiple ways to display data
  3. Multiple ways to customize the display of data
  4. Multiple options for changing cell, row, column, and header appearance and behavior

Winform Tip#5: Programmatically maximize or minimize a form

June 30, 2009 CSharp, Winform , , ,

Use the form’s WindowState property.

To minimize:

this.WindowState = System.Windows.Forms.FormWindowState.Minimized;


To maximize:

this.WindowState = System.Windows.Forms.FormWindowState.Maximized;

Winform Tip#4: Deployment in Winform

June 12, 2009 CSharp, Winform , , ,

Best way to deploy is by using ClickOnce deployment. This allows user to get regular updates, patches to the product while conforming to the security standards.


Follow on Feedly