アカウント名:
パスワード:
このエンコード方法だとデータサイズが 7 * 32bit や 7 * 64bit などを超えた段階で「他のどれよりも短いデータ長」と言うのは無理が出てきませんか? 単純に長さの情報 + バイナリ列の方がトータルサイズが短くなってしまいます。
ある程度のサイズになると、同じ方式で「データバイト長を」エンコードして、その後実データをバイナリ列で付加した方が全データ長は短くなるように思えるのですが。
もちろん、データの性格 (流すデータの各フィールド長が短いものがどれだけ多いか等) で総データ長に差が出てくるので、小さいデータが大半を占める場合にはトータルで短くなると思いますが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
XMLのコストが高いのはわかるが (スコア:0)
Re: (スコア:0)
君のお腹が一杯になると、何か解決するの？
君の許容量が低いだけ？
恐らく、こういったのはシステム全体を含めた上手い解決策がでるまで、
何回でも何年でもやり続ける作業だと思います。
その解決策が使えるのは、せいぜい数年かもしれませんが…
Re: (スコア:2, すばらしい洞察)
YAML や JSON じゃだめなの？ 正直，XDR とか ASN でもいいと思うんだけど…
XML 対 非XML という対比については分かりやすいのだけど，非 XML 同士では流派の
違いというか，審美観の問題になっている気がするです．
Re:XMLのコストが高いのはわかるが (スコア:2, 興味深い)
プロトコルバッファはVariant型でデータ長を持たない可変長の符号化を行ってる点で他のどれよりも短いデータ長になるから、データが１バイトでも短いとスループットが大きく変わるくらい流量の多いシステムではかなりコスト減につながってると思うぜ。
符号化・復号化時の速度低下も小さそうだし、このあたりはうまいね。
他のじゃこうはいかない。どれもデータかライブラリか仕様が太ってる。
Re:XMLのコストが高いのはわかるが (スコア:1)
このエンコード方法だとデータサイズが 7 * 32bit や 7 * 64bit などを超えた段階で「他のどれよりも短いデータ長」と言うのは無理が出てきませんか? 単純に長さの情報 + バイナリ列の方がトータルサイズが短くなってしまいます。
ある程度のサイズになると、同じ方式で「データバイト長を」エンコードして、その後実データをバイナリ列で付加した方が全データ長は短くなるように思えるのですが。
もちろん、データの性格 (流すデータの各フィールド長が短いものがどれだけ多いか等) で総データ長に差が出てくるので、小さいデータが大半を占める場合にはトータルで短くなると思いますが。
Re:XMLのコストが高いのはわかるが (スコア:1)
そもそも64ビットを超えません。ただ「どれよりもは」ちょっと言いすぎだったかもね。サイズの面ではASN.1のPERではメッセージの定義しだいで一長一短だし。
でも速度サイズ比ではプロトコルバッファが優勢じゃないかな。サイズでASN.1 PERが勝つ場合はビット操作の回数がかなり多そうだ。
Re: (スコア:0)
Varintな
XMLもコンパイルなり前処理して受け渡しすれば軽くもなりそうだが…
Re: (スコア:0)
Re:XMLのコストが高いのはわかるが (スコア:1, 参考になる)
To understand your simple protocol buffer encoding, you first need to understand varints. Varints are a method of serializing integers using one or more bytes. Smaller numbers take a smaller number of bytes. [google.com]
まとめとくと