Quanto è veloce o leggero il protocollo buffer?

Question

Protocol Buffer per .NET sarà leggero / più veloce di Remoting (SerializationFormat.Binary)? Ci sarà un supporto di prima classe in termini di linguaggio / quadro? cioè è gestito in modo trasparente come con Remoting / WebServices?

Answer 1

Dubito fortemente che avrà mai il supporto diretto del linguaggio o persino il supporto del framework: è il tipo di cosa che viene gestita perfettamente con librerie di terze parti.

La mia porta del codice Java è esplicita - devi chiama i metodi per serializzare / deserializzare. (Esistono stub RPC che serializzeranno / deserializzeranno automaticamente, ma nessuna implementazione RPC ancora.)

il progetto di Marc Gravell si adatta perfettamente al WCF, per quanto io sei consapevole, devi solo dirgli (una volta) di usare i buffer di protocollo per la serializzazione, e il resto è trasparente.

In termini di velocità, dovresti guardare Pagina benchmark di Marc Gravell . Il mio codice tende ad essere leggermente più veloce del suo, ma entrambi sono molto, molto più veloci delle altre opzioni di serializzazione / deserializzazione nel framework. Va sottolineato che anche i buffer di protocollo sono molto più limitati: non provano a serializzare tipi arbitrari, solo quelli supportati. In futuro cercheremo di supportare più tipi di dati comuni (decimali, DateTime ecc.) In modo portatile (come i messaggi del proprio protocollo buffer) in futuro.

Answer 2

Alcune metriche relative a prestazioni e dimensioni sono disponibili in questa pagina . Al momento non ho le statistiche di Jon lì, solo perché la pagina è un po 'vecchia (Jon: dobbiamo sistemarlo!).

Ri essendo trasparente; protobuf-net può collegarsi a WCF tramite il contratto; nota che funziona bene anche con MTOM su basic-http. Questo non funziona con Silverlight, tuttavia, poiché Silverlight non ha il punto di iniezione. Se usi svcutil, devi anche aggiungere un attributo alla classe (tramite una classe parziale).

Re BinaryFormatter (remoting); sì, questo ha pieno sostegno; puoi farlo semplicemente con una banale implementazione ISerializable (cioè chiama semplicemente il metodo Serializer con gli stessi argomenti). Se usi protogen per creare le tue classi, allora può farlo per te: puoi abilitarlo dalla riga di comando tramite argomenti (non è abilitato di default come BinaryFormatter non funziona su tutti i framework [CF, ecc.).

Si noti che per oggetti molto piccoli (singole istanze, ecc.) sul remoting locale (IPC), le prestazioni non elaborate BinaryFormatter sono effettivamente migliori - ma per grafici non banali o collegamenti remoti (remoting di rete) protobuf-net può superarlo abbastanza bene.

Dovrei anche notare che il formato del filo dei buffer di protocollo non supporta direttamente l'ereditarietà; protobuf-net può falsificarlo (pur mantenendo la compatibilità del filo), ma come con XmlSerializer, è necessario dichiarare in anticipo le sottoclassi.

---

Perché ci sono due versioni?

Immagino che le gioie dell'open source ;-p Jon ed io abbiamo già lavorato a progetti congiunti e abbiamo discusso della fusione di questi due, ma il fatto è che si rivolgono a due diversi scenari:

• dotnet-protobufs (Jon's) è una porta della versione java esistente . Ciò significa che ha un'API molto familiare per chiunque stia già utilizzando la versione java ed è costruita su costrutti java tipici (classi builder, classi di dati immutabili, ecc.) - con alcuni colpi di scena in C #.
• protobuf-net (Marc's) è una nuova implementazione lo stesso formato binario (in effetti, un requisito fondamentale è che è possibile scambiare dati tra diversi formati), ma usando i tipici idiomi .NET:
  • classi di dati mutabili (no builders)
  • le specifiche del membro di serializzazione sono espresse in attributi (paragonabile a XmlSerializer , DataContractSerializer , ecc.)

Se stai lavorando su client Java e .NET, Jon's è probabilmente una buona scelta per l'API familiare su entrambi i lati. Se sei puro .NET, protobuf-net presenta dei vantaggi: la familiare API in stile .NET, ma anche:

• non sei obbligato ad essere contratto per primo (anche se puoi, e viene fornito un generatore di codice)
• puoi riutilizzare i tuoi oggetti esistenti (infatti, le classi [DataContract] e [XmlType] possono spesso essere usate senza alcuna modifica)
• ha il pieno supporto per l'ereditarietà (che ottiene sul filo falsificando l'incapsulamento) (possibilmente univoco per un'implementazione dei buffer di protocollo? nota che le sottoclassi devono essere dichiarate in anticipo)
• fa di tutto per collegarsi e sfruttare gli strumenti .NET principali ( BinaryFormatter , XmlSerializer , WCF, DataContractSerializer ) - consentendo funziona direttamente come motore remoto. Questo sarebbe presumibilmente una grande scissione dal tronco principale di Java per il porto di Jon.

Riunendoli; Penso che saremmo entrambi aperti ad esso, ma sembra improbabile che tu voglia entrambi i set di funzionalità, poiché hanno come target requisiti così diversi.