How fast is XmlSerializer?

Note: this entry has moved.

Have you ever wondered how does the XmlSerializer really works? Well, it creates a temporary assembly that is built by reflecting the type you pass to the constructor. Wait! Don't panic because of the "reflecting" word!
It does so only once per type, and it builds an extremely efficient pair of Reader/Writer classes that will handle serialization/ deserialization during the life of the AppDomain.

These classes inherit the public XmlSerializationReader and XmlSerializationWriter classes in the System.Xml.Serialization namespace. If you want to take a look at the generated code, add the following setting to the application configuration file (web.config for a web application): 

<system.diagnostics>
  <switches>
    <add name="XmlSerialization.Compilation" value="4"/>
  </switches>
</system.diagnostics>

Now the serializer won't delete the temporary files generated in the process. For a web application, the files will be located in C:\Documents and Settings\[YourMachineName]\ASPNET\Local Settings\Temp, otherwise, they will be located in your current user Local Settings\Temp folder.
You will see code that is exactly what you would have to do if you wanted to efficiently load Xml in .NET: use nested while/if as you read, use XmlReader methods to move down the stream, etc. All the ugly code is there to make it really fast.

Special thanks to Chris Sells for his XmlSerializerCompiler utility.

4 Comments

  • The XmlSerializer has a number of constructors. If you use any of the constructors other than the one that takes a type (for example specify a type and a default namespace) then a new temporary assembly is created EVERY TIME you create a serializer, rather than only once. I can post some code to demonstrate this if you like.



    I first read about this in Dino Esposito book &quot;Applied XML Programming for Microsoft .NET&quot;. I've only tested it with one of the overloads, but I have no reason to doubt Dino on this one. Thanks for the tip re: stoping the temporary files being deleted.

  • Mmm... I haven't tested that, but I guess using harcoded namespaces at XmlSerializer construction time is not a good idea... Customizations of the generated Xml should always be done thorugh the appropriate attributes, IMO, or by modifying the XSD from which the classes can be generated.

  • We're trying to get away from XML serialization, because it is sooo bloody slow (for our purposes). I directly integrated the source that the XML serializer generates into our project and it runs great (much faster). My concern is that the source is using methods like "WriteElementStringRaw", which are not supposed to be directly used by developers. I take this to mean that Microsoft may change the implementation in the future, and I'll be stuck with source that doesn't work. What r others thoughts on using XML serializer generated code directly?

  • First, in .NET 2.0 you have a project-level setting which is under the Build tab, at the bottom: Generate Serialization Assembly. If you turn it on, you will get a compiled assembly which contains the same code you're seeing now, but it will be managed by VS and the compilation process.

    Also, I wouldn't worry too much about WriteElementStringRaw changing. When it does, all you'll need to do is update your serialization classes with fresh versions taken from the new .NET framework and that's it.

    Chances that they will break that API are very low (if non-existent altogether), because the serialization assemblies they are emitting today will break. So I'd say it's perfectly safe to use it.

Comments have been disabled for this content.