プロトコルバッファはどれくらい高速または軽量ですか？

Question

.NETのプロトコルバッファーはRemoting（SerializationFormat.Binary）よりも軽量/高速になりますか？言語/フレームワークの用語で、それに対する一流のサポートはありますか？つまり、Remoting / WebServicesと同様に透過的に処理されますか？

Answer 1

言語の直接サポートやフレームワークのサポートさえあることは非常に疑わしい-サードパーティのライブラリで完全にうまく処理されるようなものです。

Javaコードの自分のポートは明示的です。メソッドを呼び出してシリアライズ/デシリアライズします。 （RPCスタブは自動的にシリアル化/逆シリアル化されますが、RPC実装はまだありません。）

Marc Gravellのプロジェクトは、WCFに非常にうまく適合していますが、シリアル化にプロトコルバッファを使用するように（一度）指示するだけでよく、残りは透過的です。

速度の面では、マークグラヴェルのベンチマークページ。私のコードは彼よりもわずかに高速になる傾向がありますが、どちらもフレームワークの他のシリアル化/逆シリアル化オプションよりもはるかに高速です。プロトコルバッファも同様に制限されていることを指摘しておく必要があります-任意の型をシリアル化しようとはせず、サポートされている型のみをシリアル化しようとします。将来的には、より多くの一般的なデータ型（10進数、DateTimeなど）を（独自のプロトコルバッファメッセージとして）移植可能な方法でサポートする予定です。

Answer 2

一部のパフォーマンスとサイズの指標は、このページにあります。ページが少し古いという理由だけで、現時点ではJonの統計情報はありません（Jon：修正する必要があります！）。

再透過性; protobuf-net は、契約を介してWCFにフックできます。 basic-httpを介したMTOMでもうまく動作することに注意してください。ただし、Silverlightには注入ポイントがないため、これはSilverlightでは機能しません。 svcutilを使用する場合は、クラスに属性を追加する必要もあります（部分クラスを介して）。

Re BinaryFormatter（リモート処理）;はい、これには完全なサポートがあります。簡単なISerializable実装でこれを行うことができます（つまり、同じ引数でSerializerメソッドを呼び出すだけです）。 protogenを使用してクラスを作成する場合は、コマンドラインで引数を使用して有効にできます（すべてのフレームワークでBinaryFormatterが機能しないため、デフォルトでは有効になっていません[CFなど））。

ローカルリモーティング（IPC）上の非常に小さなオブジェクト（単一インスタンスなど）では、生のXmlSerializerパフォーマンスが実際に優れていることに注意してください-ただし、重要でないグラフまたはリモートリンク（ネットワークリモーティング）の場合、protobuf-netは-うまく実行します。

また、プロトコルバッファワイヤ形式は継承を直接サポートしていないことに注意してください。 protobuf-netはこれをスプーフィングできますが（ワイヤの互換性を維持しながら）、XmlSerializerと同様に、サブクラスを事前に宣言する必要があります。

---

なぜ2つのバージョンがあるのですか

オープンソースの楽しさ、-p Jonと私は以前に共同プロジェクトに取り組んでおり、これら2つを統合することについて議論しましたが、実際には2つの異なるシナリオを対象としています：

• dotnet-protobufs （Jon）は既存のJavaバージョンの移植版です。これは、すでにJavaバージョンを使用している人にとって非常に馴染みのあるAPIを持ち、いくつかのC＃のひねりを加えた典型的なJava構造（ビルダークラス、不変データクラスなど）で構築されていることを意味します。
• protobuf-net （Marc's）は、次の基礎的な再実装です。同じバイナリ形式（実際、重要な要件は、異なる形式間でデータを交換できることです）が、典型的な.NETイディオムを使用します。
  • 可変データクラス（ビルダーなし）
  • シリアル化メンバーの詳細は、属性で表されます（DataContractSerializer、[DataContract]などに相当）

javaおよび.NETクライアントで作業している場合、Jon'sはおそらく、双方の使い慣れたAPIに適した選択肢です。純粋な.NETの場合、protobuf-netには利点があります-使い慣れた.NETスタイルのAPIだけでなく、：

• コントラクトファーストに強制されることはありません （可能ですが、コードジェネレーターが提供されます）
• 既存のオブジェクトを再利用できます（実際、[XmlType]および<=>クラスはほとんど変更なしで使用できます）
• 継承を完全にサポートしています（カプセル化をスプーフィングすることでワイヤ上で実現します）（プロトコルバッファの実装に固有の場合がありますか？サブクラスは事前に宣言する必要があることに注意してください）
• コアの.NETツール（<=>、<=>、WCF、<=>）にプラグインして活用する方法がなくなり、リモーティングエンジンとして直接動作できるようになります。これはおそらく、JonのポートのメインJavaトランクからのかなり大きな分割になるでしょう。

それらを再マージします。私たちは両方に対してオープンだと思いますが、両方の機能セットがそうした異なる要件を対象としているため、両方の機能セットが必要になることはまずありません。