處理非常大的String消息的協議緩衝區？

Question

我終於能夠通過REST編寫協議緩衝區代碼，並與我們當前使用的XStream做了一些比較。一切似乎都很棒，只有一件事情絆倒。

我們必須在一個特定的屬性非常大的消息，上面說的是這樣的

message Data { 
    optional string datavalue=1; 
} 

Datavalue是非常巨大的短信。大小是512kb - 5 Mb。

協議緩衝區反序列化就好，與XStream相比具有出色的性能。 但是，我注意到，當我將此消息發送到線路（通過REST）時，獲取響應花費的時間更長。總是比XStream長兩倍。 我想這可能來自序列化時間。

從谷歌的文件，它說協議緩衝區並不旨在處理非常大的消息，雖然它可以處理非常大的數據集。

我想知道是否有人對我的案例有任何意見或解決辦法？

感謝

Answer 1

我標杆不同的序列化工具，而以前，注意到的Protobuf Java庫花了大約1.7倍，只要序列化的字符串作爲java.io.DataOutputStream一樣。當我研究它時，它似乎與JVM如何優化特定代碼路徑的奇怪工件有關。然而，在我的基準測試中，XStream總是比較慢，即使是很長的字符串也是如此。

一件簡單的事情就是使用格式兼容的Protostuff庫來代替Google的Protobuf庫。

Answer 2

我記得在某處閱讀（試圖找到文章），如果您有二進制和文本數據類型的混合，protobuf是非常好的。當你純粹使用文本數據時，你可以通過壓縮來獲得更好的性能和更大的尺寸。