解析 (シリアル化、逆シリアル化) とネットワーク経由でのパケットの送信の両方に関して、バイナリと xml のシリアル化のパフォーマンスの違いを適切に推定できますか?
4 に答える
いいえ。
これは、XML ドキュメント自体の内部にあるデータの種類に大きく依存します。構造化データが多い場合、XML のオーバーヘッドは大きくなります。たとえば、データが次のようになっているとします。
<person>
<name>Dave</dave>
<ssn>000-00-0000</ssn>
<email1>xxxxxx/email1>
</person>
...
次のような XML ドキュメントがある場合よりも、はるかに多くのオーバーヘッドが発生します。
<book name="bible">
In the beginning God created the heavens and the earth.
Now the earth was formless and empty ...
And if any man shall take away from the words of the book of this prophecy, God shall take away his part out of the book of life, and out of the holy city, and from the things which are written in this book. He which testifieth these things saith, Surely I come quickly. Amen. Even so, come, Lord Jesus.
</book>
したがって、それは本当に公正な質問ではありません。送信するデータと、それを圧縮する方法/場合に大きく依存します。
と xml シリアライゼーションの最大の違いBinaryFormatter
は移植性です。BinaryFormatter はバージョン間で保証するのが難しいため、短期間の保存または転送にのみ適しています。
ただし、オーダーメイドのバイナリ シリアライゼーションを使用することで、両方を最大限に活用し、サイズを小さくして高速にすることができます。また、自分で行う必要さえありません;-p
protobuf-netは、Google のプロトコル バッファ バイナリ シリアル化仕様の .NET 実装です。XmlSerializer
またはのいずれよりも小さくBinaryFormatter
、完全に移植可能で (バージョン間だけでなく、Java などで pb ストリームをロードできます)、拡張可能で高速です。また、かなりの数のユーザーを対象に、かなり包括的にテストされています。
XmlSerializer
、BinaryFormatter
、DataContractSerializer
および protobuf-netをカバーする、サイズと速度の完全な内訳はこちらです。
注目すべき指標は、パフォーマンスを指摘するだけではありません。
- 施工のしやすさ。シリアライザ/デシリアライザ ルーチンを構築して徹底的にテストするのに数日または数週間かかりますか?それとも、その時間を機能に費やすほうがよいでしょうか?
- データの使いやすさ。クライアントはビルド済みのオープンソース パーサーを使用できますか? それとも、(潜在的にバグのある) コードを自分で実装する必要がありますか?
- デバッグの容易さ。転送中のデータを表示できると、デバッグに役立ちますか? 次に、バイナリ形式は問題を難読化する傾向があります。
- 各方法の維持費はいくらですか?
個人的には、パフォーマンスのボトルネックが実際のテストで証明されるまでは、公開されている XML 標準とオープン ソースの解析ライブラリを使用します。
本能的にバイナリの方が効率的だと言いたくなるかもしれませんが、実際にはシリアル化されるデータに依存します。
この記事をチェックしてください: http://www.nablasoft.com/alkampfer/index.php/2008/10/31/binary-versus-xml-serialization-size/