>>>>Hi all,
>>>>
>>>>I am tracing some code that is performing slowly and found this method to be very slow in performance compared to the rest of the code in the cycle. It appears from the trace that constructing an XmlSerializer is not very quick amongst other issues Microsoft has noted with Memory (see link below).
>>>>
>>>>I am wondering about other alternatives or obvious choices you might see that could be done to speed this up. I am looking into if it is possible to keep the XmlSerializer around instead of constructing it several times but not sure if that will be a reasonable choice yet.
>>>>
>>>>I also attached a screen shot of the dot trace showing the performance metrics to this code.
>>>>Thanks
>>>>
>>>>Microsoft Link
>>>>http://support.microsoft.com/kb/886385
>>>>
>>>>
>>>>

>>>>public XmlSerializer GetXmlSerializer(Type type)
>>>>{
>>>>	XmlSerializer serializer;
>>>>	lock (SerializerCache)
>>>>	{
>>>>		if (SerializerCache.ContainsKey(type))
>>>>		{
>>>>			serializer = SerializerCache[type];
>>>>		}
>>>>		else
>>>>		{
>>>>			// Next line of code is VERY slow comparitavily and it isn't the ToArray() call.
>>>>			serializer = new XmlSerializer(type, SerializationTypesList.ToArray());
>>>>			serializer.UnknownNode += this.XmlSerializer_UnknownNode;
>>>>			serializer.UnreferencedObject += this.XMLSerializer_UnreferencedObject;
>>>>			serializer.UnknownElement += this.XMLSerializer_UnknownElement;
>>>>			serializer.UnknownAttribute += this.XMLSerializer_UnknownAttribute;
>>>>			SerializerCache.Add(type, serializer);
>>>>		}
>>>>	}
>>>>	return serializer;
>>>>}
>>>>

>>>
>>>XMlSerializer constructors build dynamic assemblies so the process will be slow. The particular constructor used above is especially inefficient and you should probably cache it. See the 'Dynamically generated assemblies' section here for an example using a hashtable:
>>>http://msdn.microsoft.com/en-us/library/system.xml.serialization.xmlserializer.aspx
>>
>>
>>Hi Viv,
>>
>>The serializer is added to the Cache and checked, but there are 37 different calls to this method all with different types. On startup there are 13 calls, one right after another and all with different types. I can't help but think there should be a cleaner more efficient way to take care of the process without this overhead. Especially when I know that creating an XmlSerializer consumes better than 25% of the total time in making a web service call. The server responds faster than this method does. I am hopeful I can find some value in doing this differently.
>
>Not clear whether the above code is server or client side. If client side you could look at sgen.exe to build the serializers at compile time: http://msdn.microsoft.com/en-us/library/bk3w6240(v=VS.100).aspx
>Seems this won't work on the server though ("These generated assemblies cannot be used on the server side of a Web service. This tool is only for Web service clients and manual serialization scenarios."). Annoyingly it doesn't explain why this is so !

Thanks Viv,

This is definately client side code and I will be looking into the compile time build with sgen.exe.
Tim