¿Por qué la serialización binaria es más rápida que la serialización xml?

Question

¿Por qué la serialización binaria se considera más rápida que la serialización xml?

Answer 1

La serialización binaria es más eficiente porque escribe datos brutos directamente y el XML necesita formato y analiza los datos para generar una estructura XML válida, dependiendo también de qué tipo de datos tengan sus objetos el XML puede tener una gran cantidad de datos redundantes .

Answer 2

Considere la serialización doble, por ejemplo:

• serialización binaria: escribir 8 bytes de dirección de memoria a la corriente

• binaria deserialización: la lectura misma de 8 bytes

• serialización XML: la escritura etiqueta, conversión a texto, escritura etiqueta de cierre - casi tres veces la E/S y 1000x más utilización de la CPU

• deserialización xml: lectura/validación de etiquetas, lectura de una cadena analizándola al número, lectura/validación de la etiqueta de cierre. poco más sobrecarga de E/S y un poco más por la CPU

Answer 3

En realidad, como todas las cosas - que depende de los datos, y el serializador.

Comúnmente (aunque quizás imprudentemente) la gente quiere decir BinaryFormatter para "binario", pero esto tiene una serie de debilidades:

• en añade un montón de tipo de metadatos (que lleva por espacio)
• por defecto incluye nombres de campo (que puede ser verboso, especialmente para propiedades implementadas automáticamente)

el contrario, xml tiene generalmente los gastos generales tales como:

• etiquetas añadir espacio y IO
• la necesidad de analizar las etiquetas (que es notablemente caro)
• las porciones de codificación de texto/decodificación

Por supuesto, xml se comprime fácilmente, añadiendo CPU pero enormemente reduciendo el ancho de banda

Pero eso no significa que uno sea más rápido; Me referiría a algunas estadísticas de muestra from here (con fuente completa incluida), a la que he anotado la base de serializador (binario, xml, texto, etc.). Mire en particular en los primeros dos resultados; parece que XmlSerializer superó BinaryFormatter en cada valor, conservando las ventajas multiplataforma. Por supuesto, protobuf luego triunfa en XmlSerializer; p

Estos números se relacionan bastante bien con ServiceStack's benchmarks, here.

BinaryFormatter *** binary 
Length: 1314 
Serialize: 6746 
Deserialize: 6268 

XmlSerializer *** xml 
Length: 1049 
Serialize: 3282 
Deserialize: 5132 

DataContractSerializer *** xml 
Length: 911 
Serialize: 1411 
Deserialize: 4380 

NetDataContractSerializer *** binary 
Length: 1139 
Serialize: 2014 
Deserialize: 5645 

JavaScriptSerializer *** text (json) 
Length: 528 
Serialize: 12050 
Deserialize: 30558 

(protobuf-net v2) *** binary 
Length: 112 
Serialize: 217 
Deserialize: 250 

Answer 4

Bueno, antes que nada, XML es un formato inflado. Cada byte que envíe en forma binaria sería similar a al menos 2 o 3 bytes en XML. Por ejemplo, al enviar el número "44" en binario, solo necesita un byte.En XML necesita una etiqueta de elemento, más dos bytes para poner el número: <N>44</N>, que es mucha más información.
Una diferencia es el tiempo de codificación/descodificación requerido para manejar el mensaje. Como los datos binarios son tan compactos, no consumirán muchos ciclos de reloj. Si los datos binarios son una estructura fija, probablemente podría cargarlos directamente en la memoria y acceder a cada elemento sin la necesidad de analizar/desagregar los datos.
XML es un formato basado en texto que necesita unos pocos pasos más para procesarse. En primer lugar, el formato está hinchado por lo que consume más memoria. Además, todos los datos son texto y es posible que los necesite en forma binaria, por lo que el XML debe analizarse. Este análisis todavía necesita tiempo para procesar, sin importar cuán rápido sea su código. ASN.1 es un formato "binario XML" que proporciona una buena alternativa para XML, pero que deberá analizarse al igual que XML. Además, si la mayoría de los datos que utiliza son texto, no numéricos, los formatos binarios no marcarán una gran diferencia.
Otro factor de velocidad es el tamaño total de sus datos. Cuando solo carga y guarda un archivo binario de 1 KB o un archivo XML de 3 KB, probablemente no notará ninguna diferencia de velocidad. Esto se debe a que los discos usan bloques de un tamaño específico para almacenar datos. Hasta 4 KB se adapta fácilmente a la mayoría de los bloques de disco. Por lo tanto, para el disco no importa si necesita leer 1 KB o 3 KB ya que lee todo el bloque de 4 KB. Pero cuando el archivo binario es de 1 megabyte y el XML es de 3 megabytes, el disco necesitará leer muchos más bloques para leer el XML. (O para escribirlo.) Y luego incluso importa si su XML es de 3 MB o solo 2.99 MB o 3.01 MB.
Con transporte sobre TCP/IP, la mayoría de los datos binarios estarán codificados en UU. Con la codificación UU, sus datos binarios crecerán con 1 byte por cada 3 bytes en los datos. Los datos XML no se codificarán, por lo que la diferencia de tamaño se reducirá, por lo que la diferencia de velocidad disminuirá. Aún así, los datos binarios seguirán siendo más rápidos ya que las rutinas de codificación/descodificación pueden ser muy rápidas.
Básicamente, el tamaño importa. :-)

Pero con XML tiene una alternativa adicional. Puede enviar y almacenar el XML en un formato de archivo ZIP. Microsoft Office hace esto con sus versiones más nuevas. Un documento de Word se crea como un archivo XML, pero se almacena como parte de un archivo ZIP más grande. Esto combina lo mejor de ambos mundos, ya que los documentos de Word son principalmente texto, por lo tanto, un formato binario no agregaría mucho aumento de velocidad. Comprimir el XML hace que el almacenamiento y el envío de datos sean mucho más rápidos simplemente haciéndolo binario. Aún más interesante, un archivo comprimido XML podría ser más pequeño que un archivo binario no comprimido, por lo que el archivo comprimido XML se convierte en el más rápido. (Pero es una trampa ya que el XML ahora es binario ...)