XML serialization is slow

Question

I inherited a project in which the application data model is an XML document. The developers in front of me created an object model based on this xml-scheme, and then encoded against the object model.

After several years of service, this application gradually began to show its age. The team leader said the key reason for this is due to the "slow" xml serialization. I am tempted to call BS about this, but many of the xml files we are dealing with are larger than 2 MB and, considering the basics of what happens behind the scenes with objects labeled [Serializable] , 2 MB has a lot to think about that there may be some truth to the theory of slowness.

In your experience, is serialization really that slow / bad to select an XML → XPath model instead of an XML → POCO model?

By the way, this is a .NET 2.0 project, and our clients can upgrade to .NET 3.5 at the end of next year.

Answer 1

In general, no, I don’t think the slowdown is due to XML serialization; 2MB is not so big, and it should not cause serious slowdown.

What interests me more is the team leader telling you what the slowdown is due to the lack of any specific profiling data. Opinions about optimization are often erroneous; profiling exists to precisely determine where the slowdown occurs in the application. I would recommend tools and application profiling, and find where the slowdown occurs; I would say that this is not in XML serialization.

Answer 2

Xml Serialization does not use the Serializable attribute. The xml serializer actually generates an assembly that maps the xml to the object and does not use reflection. This is one of the reasons Xml Serialization only works with publishing.

One thing you can try is measuring with the DataContractSerializer included with WCF. It would be interesting to see the difference.

I have never encountered a performance limitation in person, but I also do not have large objects such as a description.

One thing you should pay attention to is the constructor that you use to create the XmlSerializer , some of which do not cache the generated assembly and lead to loss of performance and memory leak, as each call will generate more and more assemblies. If so, you have two options:

1) Secure the created instance of the serializer. I believe this is thread safe, but you want to double check the MSDN.
2) The user is another constructor for creating the XmlSerializer.

Answer 3

Run the profiler and see where most of the processor time is spent. Whether it turns out to be XML serialization or somewhere else, you'll know where to focus your efforts. Also, for the record, I saw how XML serialization is surprisingly slower in the past in the Java world when working with Spring RPC. So your boss may be right, but instead of guessing, you should check.

Answer 4

As already mentioned here, I thought I wanted to indicate that in VS there is the ability to generate XML serialization assemblies during assembly.

http://msdn.microsoft.com/en-us/library/kb4wyys2(v=VS.100).aspx

You can also use sgen.exe manually to generate if you want a finer-grained control.

This reduces the time it takes to serialize a type because, as JoshBerke says, the XmlSerialiser generates a new assembly whenever it needs to serialize or deserialize, which may take time for complex types. Thus, pre-generation of your serialization builds can lead to a significant increase in performance.