クライアントのJSONを生成するサーバー側プログラムがあります。私の同僚の何人かは、ネットワークを介して送信するデータの量を減らすために、zip/gzip圧縮を使用することを提案しました。ただし、私の平均的なJSONメッセージの1つに対してテストした場合、両方とも実際に送信されるデータの量を増やしました。私が異常に大きな応答を送信するまで、ジッピングが開始されて有用でした。
それで私はstackoverflowを突っ込み始めました、そして私は最終的にLZOを見つけました、それはテストされたとき、私がしたいことを正確に実行しました。ただし、アルゴリズムの実行時のドキュメントが見つからないようです。また、コードに腰を下ろして自分で理解するのに十分ではありません:)
tl; dr？LZOの実行時間？
LZOの実行時間に関するあなたの質問（答え：ほぼ確実に十分に速い）を無視し、根本的な問題について説明します。
有線でJSONデータ構造を交換していて、帯域幅を減らしたいと考えています。現在、 DEFLATEやLZOなどの汎用圧縮アルゴリズムを検討しています。ただし、 Lempel-Ziv手法に基づく圧縮アルゴリズムは、大量のデータに対して最適に機能します。これらのアルゴリズムは、頻繁に発生するデータシーケンスのディクショナリを構築することで機能するため、シーケンスが繰り返されるときに、シーケンス全体ではなくディクショナリへの参照をエンコードできます。辞書が大きいほど、圧縮率は高くなります。個々のデータパケットのように非常に少量のデータの場合、この手法は役に立ちません。辞書を作成する時間も、多くの繰り返しが表示される時間もありません。
JSONを使用してワイヤープロトコルをエンコードしている場合、パケットはステレオタイプ化されている可能性が高く、同様の構造と少数の共通キーがあります。したがって、このユースケース用に特別に設計されたGoogleのプロトコルバッファを調査することをお勧めします。
LZOおよびその他のタイプのジェネリック/バイナリデータ圧縮アルゴリズムを回避するための提案を支持します。
他のオプションは基本的に次のとおりです。
最適な選択は、サーバー/言語の設定、速度と圧縮の要件、および個人的な好みによって異なります。私はおそらく自分でMessagePackを使用しますが、ProtocolBuffersでも問題はありません。