XmlSerializer Performance Issue when Specifying XmlRootAttribute

Just for anyone else who runs into this problem; armed with the answer above and the example from MSDN I managed to resolve this issue using the following class:

public static class XmlSerializerCache{    private static readonly Dictionary<string, XmlSerializer> cache =                            new Dictionary<string, XmlSerializer>();    public static XmlSerializer Create(Type type, XmlRootAttribute root)    {        var key = String.Format(                  CultureInfo.InvariantCulture,                  "{0}:{1}",                  type,                  root.ElementName);        if (!cache.ContainsKey(key))        {            cache.Add(key, new XmlSerializer(type, root));        }        return cache[key];    }}

Then instead of using the default XmlSerializer constructor which takes an XmlRootAttribute, I use the following instead:

var xmlRootAttribute = new XmlRootAttribute("ExampleElement");var serializer = XmlSerializerCache.Create(target.GetType(), xmlRootAttribute);

My application is now performing again!

As mentioned in the follow-up comment to the original question, .NET emits assemblies when creating XmlSerializers, and caches the generated assembly if it is created using one of these two constructors:

XmlSerializer(Type)XmlSerializer(Type, String)

Assemblies generated using the other constructors are not cached, so .NET has to generate new assemblies every time.

Why? This answer probably isn't very satisfying, but peering at this in Reflector, you can see that the key used to store and access the generated XmlSerializer assemblies (TempAssemblyCacheKey) is just a simple composite key built from the serializable type and (optionally) its namespace.

Thus, there's no mechanism to tell whether a cached XmlSerializer for SomeType has a special XmlRootAttribute or the default one.

It's hard to think of a technical reason that the key couldn't accommodate more elements, so this is probably just a feature that no one had time to implement (especially since it would involve changing otherwise stable classes).

You may have seen this, but in case you haven't, the XmlSerializer class documentation discusses a workaround:

If you use any of the other constructors, multiple versions of the same assembly are generated and never unloaded, which results in a memory leak and poor performance. The easiest solution is to use one of the previously mentioned two constructors. Otherwise, you must cache the assemblies in a Hashtable,as shown in the following example.

(I've omitted the example here)

Just had to implement something like this and used a slightly more optimized version of @Dougc's solution with a convenience overload:

public static class XmlSerializerCache {    private static readonly Dictionary<string, XmlSerializer> cache = new Dictionary<string, XmlSerializer>();    public static XmlSerializer Get(Type type, XmlRootAttribute root) {        var key = String.Format("{0}:{1}", type, root.ElementName);        XmlSerializer ser;        if (!cache.TryGetValue(key, out ser)) {            ser = new XmlSerializer(type, root);            cache.Add(key, ser);        }        return ser;    }    public static XmlSerializer Get(Type type, string root) {        return Get(type, new XmlRootAttribute(root));    }}