XML La serialización es lenta

Question

He heredado un proyecto en el que el modelo de datos de la aplicación es un documento XML. Los desarrolladores antes que yo habían creado un modelo de objetos basado en el esquema de este xml, y luego se codificaron contra el modelo de objetos.

Después de varios años de mantenimiento, esta aplicación ha comenzado gradualmente a mostrar su edad. El líder del equipo ha dicho que la razón clave detrás de esto se debe a la 'lentitud' de la serialización xml. Estoy tentado de llamar a BS sobre esto, pero muchos de los archivos xml con los que tratamos tienen más de 2MB de tamaño, y teniendo en cuenta los conceptos básicos de lo que ocurre detrás de las escenas con objetos marcados [Serializable], 2MB es mucho para reflejar entonces podría haber algo de verdad en la teoría de la lentitud.

En su experiencia, ¿la serialización es tan "lenta"/mala como para optar por un modelo XML -> XPath en lugar de un XML -> modelo POCO?

BTW este es un proyecto .NET 2.0, y nuestros clientes podrían actualizarse a .NET 3.5 en algún momento a finales del próximo año.

Answer 1

En general, no, no creo que la ralentización se deba a la serialización XML; 2 MB no es tan grande, y no debería estar causando una desaceleración importante.

Lo que más me preocupa es que el líder del equipo le diga a qué se debe la desaceleración sin darle ninguna información de perfil específica MOSTRANDO que ese es el caso. Las opiniones sobre la optimización son frecuentemente erróneas; La creación de perfiles existe con el propósito de encontrar con precisión dónde ocurre una desaceleración en una aplicación. Recomiendo instrumentar y perfilar la aplicación, y encontrar dónde está la ralentización; Apuesto a que no está en la Serialización XML.

Answer 2

Xml La serialización no usa el atributo Serializable. El serializador xml en realidad genera un ensamblado que mapea el xml al objeto, no usa el reflejo. Esta es una de las razones por las que la serialización Xml solo funciona con públicos.

Una cosa que podrías probar es medir usando el DataContractSerializer que es parte de WCF. Sería interesante ver la diferencia.

Nunca me he encontrado personalmente con una limitación de rendimiento pero tampoco tengo objetos grandes como su descripción.

Una cosa a tener en cuenta es el constructor que use para crear el XmlSerializer, algunos de ellos no almacenan en caché el ensamblado generado y provocarán una pérdida de rendimiento y una pérdida de memoria ya que cada llamada generará más y más ensamblados . Si este es el caso, tiene dos opciones:

1) Guarde en caché la instancia del serializador que ha creado. Creo que es seguro para subprocesos, pero querrá verificar dos veces MSDN.
2) Usuario un constructor diferente para crear el XmlSerializer.

Answer 3

Ejecute un generador de perfiles y vea dónde se está gastando la mayor parte del tiempo de la CPU. Ya sea que se trate de la serialización XML o en otro lugar, sabrá dónde enfocar sus esfuerzos. Además, para el registro, he visto que la serialización de XML es sorprendentemente lenta en el pasado en el mundo de Java cuando se trabaja con Spring RPC. Por lo tanto, es posible que su jefe tenga razón, pero en lugar de adivinar, debe verificar.

Answer 4

Como no se ha mencionado aquí todavía, pensé que señalaría que hay una opción en VS para generar ensamblados de serialización XML en tiempo de compilación.

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

También es posible usar sgen.exe manualmente para hacer la generación si desea tener un control más preciso.

Esto reduce el tiempo necesario para serializar un tipo porque, como dice JoshBerke anteriormente, XmlSerialiser genera un nuevo ensamblado cada vez que necesita serisliser o deserialise, lo que puede llevar tiempo para tipos complejos. La pregeneración de sus ensambles de serialización puede resultar en mejoras significativas en el rendimiento.