簡介
結構化數據的序列化是通過網絡傳輸信息或存儲數據的關鍵步驟，因為這是一個非常佔用CPU的任務。 實際上，在許多通信方案中，瓶頸都是數據序列化和反序列化。
開發序列化需要考慮跨平臺跨語言，因為現在的系統都是在分佈式系統上進行數據交換。
在Web服務和REST中使用的是基於冗長序列化格式（例如XML或JSON），它在性能上暴露出非常巨大的問題，因此人們迫切需要一種性能高的序列化方式。 因為大公司有著分佈式系統和雲計算，因此他們更需要一種快速二進制格式和輕量級遠程過程調用（RPC）框架。 於是我們比較看到了Apache Thrift，Protobuf，Fast的誕生。
Protobuf是Google開發的一種替代方案，旨在比XML更快更小。 協議緩衝區是Google幾乎所有機器間通信中使用的自定義RPC引擎的基礎。
Apache Thrift是一個在Facebook公司廣泛使用的RPC框架，旨在提供“可擴展的跨語言服務開發”。
eProsima Fast Buffers是另一個序列化替代產品，它是一種針對性能進行優化的開源序列化引擎，它基於CDR（通用數據表示）（OMG（對象管理組）的標準序列化格式）。
這三個序列化方案根據數據結構定義生成序列化和反序列化代碼。 開發人員在文件中使用接口定義語言（IDL）定義其數據結構，然後工具將解析該文件以生成序列化和反序列化代碼。
我們還將考慮eProsima動態快速緩衝區的eProsima快速緩衝區的一種變體。 在這種情況下，不需要IDL，eProsima提供一個API可以在運行時描述您的數據類型，從而動態生成（反）序列化支持。
性能比較
我們的目標是使用不同大小的簡單和複雜結構來衡量對這些方案進行數據結構序列化和反序列化的總時間，以獲取完整的性能報告。
我們將使用兩種不同的數據結構：
- 簡單結構：長整數字段。
- 複雜結構：涵蓋受支持數據類型的字段。
為了獲得準確的測量結果，我們執行了一百萬次序列化和反序列化操作，測量了測試的總時間，以便稍後獲得一個完整週期的時間。
結論：eProsima快速緩衝區在支持靜態序列化的情況下更好，而在動態情況下Protubuf和eProsima相對更好一些。
總結
在所有情況下，eProsima快速緩衝區都是最快的序列化機制。因為它使用了CDR的優化實現。
這種序列化格式在DDS（一種用於非常緊急的實時應用程序的中間件）中使用。
與本文分析的其餘技術相比，Apache Thrift TBinaryProtocol確實很慢。節儉格式會添加一個數字來標識每個字段，以便允許可選字段和必填字段，並鍵入擴展性。看來在性能方面的價格確實很高。
Google Protocol Buffers速度很快，但不如eProsima Fast Buffers快，並且類似於eProsima Dynamic Fast Buffers。
eProsima使用可變大小的整數（varint）對整數進行編碼：用於編碼整數的字節取決於該值。對於包含一些整數的結構，這會導致較小的編碼大小，從而影響性能。
考慮到序列化，eProsima Dynamic Fast Buffers具有非常好的性能，並且反序列化邏輯不是預先編譯的，而是在運行時生成的。該框架根據數據結構定義動態創建“（反）序列化字節碼”，並解釋該字節碼。
與傳統代碼生成相比，解釋此字節碼的過程僅增加了大約20-30％的性能開銷。當您在編譯時不知道數據的結構（用戶定義的結構，數據可視化應用程序...），或者只是不想維護外部IDL文件時，可以使用動態序列化。
閱讀更多 夢迴故里歸來 的文章
