C ++ Desempenho serialização

Question

Estou construindo uma aplicação distribuída C ++ que precisa fazer muita serialização e desserialização de estruturas de dados simples que está sendo passadas entre diferentes processos e computadores.

Eu não estou interessado em serialização hierarquias de classe complexas, mas mais do envio de estruturas com alguns membros simples, como números, strings e vetores de dados. Os vetores de dados muitas vezes pode ser muitos megabytes grande. Eu estou preocupado que texto / formas baseadas em XML de fazê-lo é muito lento e eu realmente não quero escrever isso mesmo, desde problemas como a codificação de cordas e número endianess pode torná-lo muito mais complicado do que parece na superfície.

Eu estive procurando um pouco de buffers de protocolo e boost.serialize. De acordo com os buffers de protocolo documentos parece se importar muito com o desempenho. Impulso parece um pouco mais leve no sentido de que você não tem uma linguagem externa para especificar o formato dos dados que eu acho bastante conveniente para este projecto específico.

Então, minha pergunta se resume a isto:? Alguém sabe se o impulso de serialização é rápido para o caso de uso típico que eu descrevi acima

Além disso, se há outras bibliotecas que pode ser bom para isso, eu ficaria feliz em ouvir sobre eles.

Answer 1

Gostaria de sugerir buffers de protocolo. Eles são incrivelmente simples de usar, oferecem grande desempenho, e cuidar de questões como a ordenação e compatibilidade com versões anteriores. Para torná-lo ainda mais atraente, os dados serializados é independente do idioma graças às inúmeras implementações de linguagem.

Answer 2

ACE e ACE TAO vêm à mente, mas você pode não gostar do tamanho e escopo do mesmo. http://www.cs.wustl.edu/~schmidt/ACE.html

Quanto à sua pergunta sobre "rápido" e impulso. Isso é um termo subjetivo e sem saber suas exigências (rendimento, etc) é difícil responder isso para você. Não que eu tenha qualquer referência para o material boost me ...

Não são mensagens camadas que você pode usar, mas esses são, provavelmente, mais lento do que impulso. Eu diria que você identificou uma boa solução no impulso, mas eu só usei ACE e outras comunicações proprietárias / produtos de mensagens.

Answer 3

Meu palpite é que o impulso é rápido o suficiente. Eu usei-o em projectos anteriores com dados serialize de e para o disco, e seu desempenho nunca sequer surgiu como um problema.

responder aqui fala sobre a serialização em geral, que pode ser útil para você além do qual biblioteca de serialização que você escolher para uso.

Dito isto, parece que você conhece a maioria dos principais pontos de conflito com a serialização (string codificação endianess). Você deixou fora de versão e para a frente / trás compatibilidade. Se o tempo não é crítico Eu recomendo escrever o seu próprio código de serialização. É uma experiência esclarecedora, e as lições que você aprende são inestimáveis. Embora eu vou avisá-lo, ele tenderá a fazer com que você odeia protocolos baseados em XML para o seu bloatedness. :)

Seja qual for o caminho que você escolher boa sorte com seu projeto.

Answer 4

Também confira ONC-RPC (Old Sun-RPC)

Answer 5

boost.serialization não se preocupa com codificações corda ou endianness. Você vai ser igualmente bem fora não usá-lo se o que importa para você.

Você pode querer olhar para ICE de zeroc: http://www.zeroc.com/

Ele funciona semelhante ao CORBA, exceto que é totalmente specced e definidos pela empresa. A vantagem é que as implementações funcionar como o esperado, uma vez que não são todos que muitos. A desvantagem é que se você estiver usando uma linguagem que eles não suportam, você está sem sorte.

Answer 6

Se você está apenas enviando estruturas de dados definidas bem definidas, então talvez você deve estar olhando para ASN .1 como uma metodologia de codificação?

Answer 7

Há também Thrift, que se parece com um projeto alfa, mas é usado e desenvolvido pelo Facebook , por isso tem alguns utilizadores do mesmo.

Ou o bom e velho DCE , que foi o MS padrão decidiu usar para COM. Seu agora open-source, 20 anos atrasado, mas melhor que nunca.

Answer 8

otimizar Não preventivamente. Meça primeiro e otimizar segundo.