1

POC として、私は XML Web サービスでの Protobuf シリアライゼーションの推定速度と低メモリ (ネットワーク) フットプリントから利益を得る可能性を検討していました。

したがって、次のようなメッセージを生成する代わりに:

<message>
  <author>Bob</author>
  <text>Hello John!</text>
  <date>1351875211751</date>
</message>

私は次のようなものを生成します

<message>Cg5IZWxsbyBVbmtub3duIRIEQmlsbBiGteSPrCc=</message>

Protobuf メッセージの base64 エンコーディングを使用します。さて、base64 レイヤーを導入すると、Protobuf を使用する目的全体 (速度と帯域幅の節約) が台無しになるのではないでしょうか?

4

2 に答える 2

3

さて、base64 レイヤーを導入すると、Protobuf を使用する目的全体 (速度と帯域幅の節約) が台無しになるのではないでしょうか?

それはデータに依存します。短い名前のフィールドが少数で、値ごとに多くのデータがある場合、はい、大きくなります。

短い値を持つフィールドが多数ある場合、XML タグのサイズがデータを圧倒します。例えば：

<message>
  <verylongname1>x</verylongname1>
  <verylongname2>y</verylongname2>
  <verylongname3>z</verylongname3>
</message>

protobuf 形式では、XML では名前が 2 回あるため、フィールドごとに多くのオーバーヘッドが発生するのに比べて、フィールドごとに数バイトしかありません。base64 エンコーディングでは、データ サイズに定数の 4/3 を掛けても、まだ良い結果が得られます。

もちろん、それは圧縮がないことを前提としています。XML を圧縮すれば、多くの欠点がなくなりますが、base64 protobuf がほぼ同じように圧縮されるとは思えません。圧縮を使用しているかどうかはわかりません。

また、XML の診断上の魅力についても考慮する必要があります。base64 デコーダーに続いて protobuf プリンターを介してデータを実行する必要はありません。

結論：これは、データと、それを使って何をしているのかによって異なります。もちろん、XML や protobuf 以外にもシリアライゼーション スキームはあります。たとえば、jsonを考えてみましょう...

于 2012-11-02T17:09:38.160 に答える