Più grandi differenze di buffer di risparmio rispetto al protocollo?

Entrambi offrono molte delle stesse funzionalità; tuttavia, ci sono alcune differenze:

• Thrift supporta 'eccezioni'
• I buffer di protocollo hanno una documentazione/esempi molto migliori
• Il risparmio ha un tipo Set incorporato
• I buffer di protocollo consentono "estensioni": è possibile estendere un proto esterno per aggiungere campi aggiuntivi, consentendo comunque al codice esterno di operare sui valori. Non c'è modo di farlo in Thrift
• Trovo molto più facile leggere i buffer di protocollo

Fondamentalmente, sono abbastanza equivalenti (con i buffer di protocollo leggermente più efficienti da quello che ho letto).

Un'altra importante differenza sono le lingue supportate di default.

• Buffer di protocollo: Java, Android Java, C++, Python, Ruby, C #, Go, Objective-C, Node.js
• Parsimonia: Java, C++, Python, Ruby, C #, Go, Objective-C, JavaScript, Node.js, Erlang, PHP, Perl, Haskell, Smalltalk, OCaml, Delphi, D, Haxe

Entrambi possono essere estesi ad altre piattaforme, ma queste sono le combinazioni di lingue disponibili immediatamente.

RPC è un'altra differenza fondamentale. La parsimonia genera codice per implementare client e server RPC in cui il protocollo Buffer sembra progettato principalmente come formato di scambio dati.

• Gli oggetti serializzati Protobuf sono circa il 30% più piccoli di Thrift.
• La maggior parte delle azioni che potresti voler fare con gli oggetti protobuf (creare, serializzare, deserializzare) sono molto più lente della parsimonia a meno che tu non accenda option optimize_for = SPEED . 
• La parsimonia ha strutture dati più ricche (Mappa, Imposta)
• L'API di Protobuf sembra più pulita, anche se le classi generate sono tutte confezionate come classi interne che non sono così belle.
• Le enumerazioni del tempo non sono vere e proprie enumerazioni di Java, cioè sono solo intarsi. Protobuf ha vere e proprie enumerazioni di Java.

Per uno sguardo più attento alle differenze, controlla il codice sorgente diff in questo progetto open source .

Come ho detto come "Buffer di protocollo rispetto al protocollo" topic:

Riferendosi a Confronto tra Protobuf e Confronto JSON :

• Thrift supporta out of the box AS3, C++, C #, D, Delphi, Go, Graphviz, Haxe, Haskell, Java, Javascript, Node.js, OCaml, Smalltalk, TypeScript, Perl, PHP, Python, Ruby, ..
• C++, Python, Java - supporto in-box in Protobuf 
• Il supporto di Protobuf per altre lingue (inclusi Lua, Matlab, Ruby, Perl, R, Php, OCaml, Mercury, Erlang, Go, D, LISP) è disponibile come componenti aggiuntivi di terze parti (btw. Ecco SWI- Supporto Prolog ).
• Protobuf ha una documentazione molto migliore e molti esempi.
• Il risparmio arriva con un buon tutorial
• Gli oggetti Protobuf sono più piccoli
• Protobuf è più veloce quando unsing "optimize_for = SPEED"
• Thrift ha integrato l'implementazione RPC, mentre per le soluzioni Roto Protobuf sono separate, ma disponibili (come Zeroc ICE ).
• Protobuf è rilasciato sotto licenza BSD
• Thrift è rilasciato sotto licenza Apache 2

Inoltre, ci sono molti strumenti aggiuntivi interessanti disponibili per queste soluzioni, che potrebbero decidere. Ecco alcuni esempi di Protobuf: Protobuf-wireshark , protobufeditor .

Sono riuscito a ottenere prestazioni migliori con un protocollo basato su testo rispetto a protobuff su python. Tuttavia, nessun tipo di controllo o altra conversione utf8 di fantasia, ecc ... che offre il protobuff.

Quindi, se la serializzazione/deserializzazione è tutto ciò di cui hai bisogno, probabilmente puoi usare qualcos'altro.

http://dhruvbird.blogspot.com/2010/05/protocol-buffers-vs-http.html

Una cosa ovvia non ancora menzionata è che può essere sia un pro che un contro (ed è lo stesso per entrambi) è che sono protocolli binari. Ciò consente una rappresentazione più compatta e possibilmente più prestazioni (pro), ma con una leggibilità ridotta (o piuttosto una debugabilità), una truffa.

Inoltre, entrambi hanno un supporto degli strumenti leggermente inferiore rispetto ai formati standard come xml (e forse anche json).

(EDIT) Ecco un Confronto interessante che affronta sia le differenze di dimensioni e prestazioni, e include anche i numeri per alcuni altri formati (xml, json).

Protocol Buffers sembra avere una rappresentazione più compatta, ma questa è solo l'impressione che ottengo leggendo il white paper di Thrift. Nelle loro stesse parole:

Abbiamo deciso di evitare alcune ottimizzazioni di archiviazione estreme (ad esempio, imballare Numeri interi piccoli in ASCII o utilizzare un formato di continuazione a 7 bit) per motivi di semplicità e chiarezza nel codice. Queste alterazioni può essere fatto facilmente se e quando incontriamo un critico delle prestazioni usa il caso che li richiede.

Inoltre, potrebbe essere solo una mia impressione, ma i Protocol Buffers sembrano avere alcune astrazioni più spesse attorno al controllo delle versioni delle struct. Thrift ha qualche supporto per le versioni, ma ci vuole un po 'di sforzo per farlo accadere.

ProtocolBuffers è più veloce.
C'è un punto di riferimento di Nizza qui:
http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking

Potresti anche voler guardare in Avro, dato che Avro è ancora più veloce.
Microsoft ha un pacchetto qui:
http://www.nuget.org/packages/Microsoft.Hadoop.Avro ​​

A proposito, il più veloce che abbia mai visto è Cap'nProto ;
Un'implementazione C # può essere trovata nel repository Github di Marc Gravell .

E secondo il wiki il runtime di Thrift non funziona su Windows.

Penso che la maggior parte di questi punti abbia ignorato il fatto fondamentale che Thrift è un framework RPC, che ha la capacità di serializzare i dati usando una varietà di metodi (binario, XML, ecc.).

I buffer di protocollo sono progettati esclusivamente per la serializzazione, non è un framework come Thrift. 

Per uno, protobuf non è un'implementazione RPC completa. Richiede qualcosa come gRPC per andare con esso. 

gPRC è molto lento rispetto a Thrift:

http://szelei.me/rpc-benchmark-part1/

È anche importante notare che non tutte le lingue supportate sono compatibili con parsimonia o protobuf. A questo punto si tratta dell'implementazione dei moduli oltre alla serializzazione sottostante. Fai attenzione a verificare i benchmark per la lingua che intendi utilizzare.

Ci sono alcuni punti eccellenti qui e ne aggiungerò un altro nel caso in cui il percorso di qualcuno qui attraversi.

Thrift ti offre la possibilità di scegliere tra serializzatore compatto e parsimonioso (de), il binario di risparmio avrà una prestazione eccellente ma dimensioni del pacchetto maggiori, mentre il compatto di risparmio energetico offrirà una buona compressione ma richiederà più potenza di elaborazione. Questo è utile perché puoi sempre passare da una modalità all'altra con la stessa facilità con cui si modifica una linea di codice (diamine, persino rendendola configurabile). Quindi, se non si è sicuri di quanto l'applicazione debba essere ottimizzata per le dimensioni del pacchetto o per la potenza di elaborazione, la parsimonia può essere una scelta interessante.

PS: guarda questo eccellente progetto di benchmark di thekvs che mette a confronto molti serializzatori tra cui parsimonia-binario, parsimonioso e protobuf: https://github.com/thekvs/cpp-serializers

PS: C'è un altro serializzatore chiamato YAS che fornisce anche questa opzione ma è senza schema vedere il link sopra.