Prestazioni di serializzazione C ++

Question

Sto costruendo un'applicazione C ++ distribuita che deve eseguire molta serializzazione e deserializzazione di strutture dati semplici che vengono passate tra processi e computer diversi.

Non sono interessato a serializzare gerarchie di classi complesse, ma piuttosto a inviare strutture con pochi membri semplici come numero, stringhe e vettori di dati. I vettori di dati possono spesso essere di molti megabyte. Sono preoccupato che i modi di farlo basati su testo / xml siano troppo lenti e non voglio davvero scriverlo da solo poiché problemi come la codifica delle stringhe e l'endianità dei numeri possono renderlo più complicato di quanto sembri in superficie.

Ho cercato un po 'i buffer di protocollo e boost.serialize. Secondo i documenti, i buffer di protocollo sembrano preoccuparsi molto delle prestazioni. Boost sembra un po 'più leggero, nel senso che non hai una lingua esterna per specificare il formato dei dati che trovo abbastanza conveniente per questo particolare progetto.

Quindi la mia domanda si riduce a questo: qualcuno sa se la serializzazione boost è veloce per il tipico caso d'uso che ho descritto sopra?

Inoltre, se ci sono altre librerie che potrebbero essere adatte a questo, sarei felice di conoscerle.

Answer 1

Consiglio vivamente i buffer di protocollo. Sono incredibilmente semplici da usare, offrono grandi prestazioni e si occupano di problemi come l'endianness e la retrocompatibilità. Per renderlo ancora più attraente, i dati serializzati sono indipendenti dalla lingua grazie a numerose implementazioni linguistiche.

Answer 2

ACE e ACE TAO vengono in mente, ma potresti non apprezzarne le dimensioni e la portata. http://www.cs.wustl.edu/~schmidt/ACE.html

Per quanto riguarda la tua domanda su " veloce " e aumentare. Questo è un termine soggettivo e senza conoscere le vostre esigenze (rendimento, ecc.) È difficile rispondere a questo per voi. Non che io stesso abbia dei parametri di riferimento per le cose boost ...

Ci sono livelli di messaggistica che puoi usare, ma probabilmente sono più lenti di boost. Direi che hai identificato una buona soluzione in boost, ma ho usato solo ACE e altri prodotti di comunicazione / messaggistica proprietari.

Answer 3

La mia ipotesi è che la spinta è abbastanza veloce. L'ho usato in progetti precedenti per serializzare i dati da e verso il disco e le sue prestazioni non sono mai state considerate un problema.

La mia answer qui parla di serializzazione in generale, che può esserti utile oltre la libreria di serializzazione che scegli di utilizzare.

Detto questo, sembra che tu conosca la maggior parte dei principali punti problematici con la serializzazione (codifica stringa endianess). Hai tralasciato il controllo delle versioni e la compatibilità con le versioni precedenti. Se il tempo non è critico, ti consiglio di scrivere il tuo codice di serializzazione. È un'esperienza illuminante e le lezioni che impari sono preziose. Anche se ti avvertirò, tenderà a farti odiare i protocolli basati su XML per la loro gonfiore. :)

Qualunque percorso scegliate buona fortuna con il vostro progetto.

Answer 4

Dai un'occhiata anche a ONC-RPC (vecchio SUN-RPC)

Answer 5

boost.serialization non si preoccupa di codifiche di stringa o endianness. Allo stesso modo starai bene a non usarlo se questo è importante per te.

Potresti voler esaminare ICE da ZeroC: http://www.zeroc.com/

Funziona in modo simile a CORBA, tranne per il fatto che è interamente ipotizzato e definito dalla società. Il lato positivo è che le implementazioni funzionano come previsto, dal momento che non ce ne sono così tante. L'aspetto negativo è che se stai usando una lingua che non supportano, sei sfortunato.

Answer 6

Se stai inviando solo strutture di dati ben definite, forse dovresti guardare ASN .1 come metodologia di codifica?

Answer 7

C'è anche Thrift , che sembra un progetto alfa ma è utilizzato e sviluppato da Facebook , quindi ne ha alcuni utenti.

O buon vecchio DCE , che era lo standard MS che ha deciso di utilizzare per COM. Ora è open-source, 20 anni in ritardo, ma meglio che mai.

Answer 8

Non ottimizzare preventivamente. Misura prima e ottimizza la seconda.