Rendimiento de serialización de C ++

Question

Estoy creando una aplicación distribuida de C ++ que necesita mucha serialización y deserialización de estructuras de datos simples que se pasan entre diferentes procesos y computadoras.

No estoy interesado en serializar jerarquías de clases complejas, sino más bien en enviar estructuras con algunos miembros simples, como números, cadenas y vectores de datos. Los vectores de datos a menudo pueden tener muchos megabytes de tamaño. Me preocupa que las formas de hacerlo basadas en texto / xml sean demasiado lentas y realmente no quiero escribir esto yo mismo, ya que problemas como la codificación de cadenas y la endianess de números pueden hacer que sea mucho más complicado de lo que parece en la superficie.

He estado mirando un poco los buffers de protocolo y boost.serialize. De acuerdo con los documentos, los buffers de protocolo parecen preocuparse mucho por el rendimiento. Boost parece algo más liviano en el sentido de que no tiene un lenguaje externo para especificar el formato de datos que considero bastante conveniente para este proyecto en particular.

Entonces mi pregunta se reduce a esto: ¿alguien sabe si la serialización de impulso es rápida para el caso de uso típico que describí anteriormente?

Además, si hay otras bibliotecas que podrían ser adecuadas para esto, me encantaría saber de ellas.

Answer 1

Sugeriría encarecidamente los buffers de protocolo. Son increíblemente fáciles de usar, ofrecen un gran rendimiento y se ocupan de problemas como la resistencia y la compatibilidad con versiones anteriores. Para hacerlo aún más atractivo, los datos serializados son independientes del idioma gracias a numerosas implementaciones de idiomas.

Answer 2

ACE y ACE TAO vienen a la mente, pero es posible que no le guste el tamaño y el alcance de la misma. http://www.cs.wustl.edu/~schmidt/ACE.html

Con respecto a su consulta sobre "rápido" e impulsar. Es un término subjetivo y sin conocer sus requisitos (rendimiento, etc.) es difícil responder eso por usted. No es que yo tenga ningún punto de referencia para las cosas de impulso ...

Hay capas de mensajería que puede usar, pero probablemente sean más lentas que el refuerzo. Diría que identificó una buena solución en boost, pero solo he usado ACE y otros productos de comunicaciones / mensajería patentados.

Answer 3

Mi suposición es que el impulso es lo suficientemente rápido. Lo he usado en proyectos anteriores para serializar datos hacia y desde el disco, y su rendimiento nunca llegó a ser un problema.

Mi respuesta aquí habla sobre la serialización en general, que puede ser útil para usted más allá de la biblioteca de serialización que elija utilizar.

Dicho esto, parece que conoces la mayoría de los principales puntos problemáticos con la serialización (codificación de cadena de endianess). Dejó de lado el control de versiones y la compatibilidad hacia adelante / hacia atrás. Si el tiempo no es crítico, recomiendo escribir su propio código de serialización. Es una experiencia esclarecedora, y las lecciones que aprendes son invaluables. Aunque te advertiré, tenderá a hacerte odiar los protocolos basados ??en XML por su hinchazón. :)

Cualquiera que sea el camino que elija, buena suerte con su proyecto.

Answer 4

Consulte también ONC-RPC (antiguo SUN-RPC)

Answer 5

boost.serialization no se preocupa por las codificaciones de cadena o endianness. De igual manera, no lo usará si eso le importa.

Es posible que desee consultar ICE desde ZeroC: http://www.zeroc.com/

Funciona de manera similar a CORBA, excepto que está completamente especificado y definido por la compañía. Lo bueno es que las implementaciones funcionan según lo previsto, ya que no hay tantas. La desventaja es que si estás usando un idioma que no admiten, no tienes suerte.

Answer 6

Si solo está enviando estructuras de datos bien definidas, entonces quizás debería estar mirando ASN .1 como metodología de codificación?

Answer 7

También hay Thrift , que parece un proyecto alfa, pero Facebook lo utiliza y lo desarrolla , por lo que tiene algunos usuarios.

O bien DCE , que era el estándar que MS decidió usar para COM. Ahora es de código abierto, 20 años demasiado tarde, pero mejor que nunca.

Answer 8

No optimices de forma preventiva. Mida primero y optimice segundo.