views:

871

answers:

3

I've inherited a project where the application's data model is an XML document. The developers before me had created an object model based on this xml's schema, and then coded against the object model.

After several years of maintenance, this application has gradually started to show its age. The team leader has said that the key reason behind this is due to the 'slowness' of xml serialization. I'm tempted to call BS on this, but many of the xml files we deal with are over 2MB in size, and keeping in mind the basics of what goes on behind the scenes with objects marked [Serializable], 2MB is a lot to reflect over so there might be some truth to the slowness theory.

In your experience, is serialization really so 'slow'/bad as to opt for a xml->xpath model instead of a xml->poco model?

BTW this is a .net 2.0 project, and our clients might be upgrading to .net 3.5 sometime late next year.

+6  A: 

Xml Serialization does not use the Serializable attribute. The xml serializer actually generates an assembly which maps the xml to the object, it doesn't use reflection. This is one of the reasons Xml Serialization only works with publics.

One thing you could try is measure using the DataContract Serializer that is part of WCF. It'd be interesting to see the difference.

I have never ran into a performance limitation personally but I also don't have large objects such as your describing.

One thing to watch out for is the constructor your using to create the Xml Serializer, some of them do not cache the generated assembly and will result in a loss of performance and a memory leak as each call will generate more and more assemblies. If this is the case you have two options:

1) Cache the serializer instance you created. I believe it is thread safe but you'll want to double check MSDN.
2) User a different constructor to create the XmlSerializer.

JoshBerke
+1 great answer. As an aside, I recall seeing some benchmarks on DataContractSerializer that showed it on average being about 10% faster than the XmlSerializer.
womp
+5  A: 

In general, no, I don't think the slowdown is due to the XML Serialization; 2MB isn't that large, and it shouldn't be causing any major slowdown.

What I'd be more concerned about is the team leader telling you what the slowdown is due to without giving you any specific profiling information SHOWING you that that's the case. Opinions about optimization are frequently wrong; profiling exists for the purpose of precisely finding where any slowdown is going on in an app. I'd recommend instrumenting and profiling the app, and finding where the slowdown is; I'd bet it's not in the XML Serialization.

McWafflestix
+1  A: 

Run a profiler and see where most of the CPU time is being spent. Whether it turns out to be the XML serialization or somewhere else, you'll know where to focus your efforts. Also, for the record, I've seen XML serialization being surprisingly slow in the past in the Java world when working with Spring RPC. So, it's certainly possible your boss is right, but rather than guessing, you should check.

Yevgeniy Brikman