Protocol Bufferはどれくらい高速または軽量ですか？
.NETのProtocolBufferは、Remoting（SerializationFormat.Binary）よりも軽量/高速になりますか？言語/フレームワークの観点から、ファーストクラスのサポートはありますか？つまり、Remoting/WebServicesのように透過的に処理されますか？
直接の言語サポートやフレームワークのサポートさえもあるのではないかと私は非常に疑っています。これは、サードパーティのライブラリで完全にうまく処理されるようなものです。
Java code の私自身のポートは明示的です-シリアル化/逆シリアル化するメソッドを呼び出す必要があります（自動的にシリアル化/逆シリアル化するRPCスタブがありますが、 RPCの実装はまだです。）
Marc Gravellのプロジェクト WCFと非常にうまく適合しますが、-私が知る限り、シリアル化にプロトコルバッファを使用するように（一度）指示するだけで、残りは透過的です。
速度に関しては、 Marc Gravellのベンチマークページ を参照してください。私のコードは彼よりもわずかに速い傾向がありますが、どちらもフレームワークの他のシリアル化/逆シリアル化オプションよりもはるかに高速です。プロトコルバッファもはるかに制限されていることを指摘しておく必要があります。これらは任意のタイプをシリアル化しようとはせず、サポートされているタイプのみをシリアル化します。将来的には、より多くの一般的なデータ型（decimal、DateTimeなど）を（独自のプロトコルバッファメッセージとして）移植可能な方法でサポートするように努めます。
いくつかのパフォーマンスとサイズのメトリクスは このページ にあります。ページが少し古いという理由だけで、現時点ではJonの統計情報を取得していません（Jon：修正する必要があります！）。
透明である; protobuf-net コントラクトを介してWCFにフックできます。基本httpよりもMTOMでうまく機能することに注意してください。ただし、Silverlightには注入ポイントがないため、これはSilverlightでは機能しません。 svcutilを使用する場合は、（部分クラスを介して）クラスに属性を追加する必要もあります。
Re BinaryFormatter（リモーティング）;はい、これには完全なサポートがあります。これは、簡単なISerializable実装で簡単に実行できます（つまり、同じ引数でSerializerメソッドを呼び出すだけです）。 protogenを使用してクラスを作成すると、それを実行できます。これは、コマンドラインで引数を使用して有効にできます（BinaryFormatterは有効にしないため、デフォルトでは有効になりません）。すべてのフレームワークで動作します[CFなど]）。
ローカルリモーティング（IPC）上の非常に小さなオブジェクト（単一インスタンスなど）の場合、生のBinaryFormatterパフォーマンスは実際には優れていますが、重要なグラフまたはリモートリンク（ネットワークリモーティング）の場合、protobuf-netは-それをかなりうまく実行します。
また、プロトコルバッファのワイヤ形式は継承を直接サポートしていないことにも注意してください。 protobuf-netは（ワイヤ互換性を維持しながら）これをスプーフィングできますが、XmlSerializerと同様に、サブクラスを事前に宣言する必要があります。
なぜ2つのバージョンがあるのですか？
オープンソースの喜びは、私が推測する; -p Jonと私は以前に共同プロジェクトに取り組み、これら2つをマージすることについて議論しましたが、実際には、2つの異なるシナリオを対象としています。
- dotnet-protobufs （Jon's）は、既存のJavaバージョンのポートです。これは、すでにJavaバージョンであり、典型的なJava構造（ビルダークラス、不変データクラスなど）に基づいて構築されています-いくつかのC＃のひねりがあります。
- protobuf-net （Marc's）は、同じバイナリ形式（実際、重要な要件は、異なる形式間でデータを交換できることです）に従いますが、一般的な.NETイディオムを使用したゼロからの再実装です。
- 可変データクラス（ビルダーなし）
- シリアル化メンバーの詳細は、属性で表されます（
XmlSerializer、DataContractSerializerなどと比較して）
Javaおよび.NETクライアントで作業している場合は、Jon'sがおそらく両側の使い慣れたAPIに適しています。純粋な.NETの場合、protobuf-netには利点があります-使い慣れた。 NETスタイルのAPIだけでなく、次の機能もあります。
- 強制されていない（ただし、可能であり、コードジェネレーターが提供されています）
- 既存のオブジェクトを再利用できます（実際、
[DataContract]および[XmlType]クラスは、ほとんど変更なしで使用できることがよくあります） - 継承を完全にサポートしています（カプセル化をスプーフィングすることでネットワーク上で実現します）（プロトコルバッファの実装ではおそらく一意ですか？サブクラスは事前に宣言する必要があることに注意してください）
- コア.NETツール（
BinaryFormatter、XmlSerializer、WCF、DataContractSerializer）にプラグインして悪用することはできず、リモートエンジンとして直接機能することができます。これはおそらく、JonのポートのメインJavaトランクからのかなり大きな分割になるでしょう。
それらを再マージします。私たちは両方ともそれにオープンであると思いますが、それらはそのような異なる要件を対象としているため、両方の機能セットが必要になる可能性は低いようです。