ProtocolBuffer VS AMF3（fixed）

感謝Atry的指導，筆者修改了一下範例，以求更客觀的比較結果，順便也比較一下修改前及修改後的效能差異

主要修改的有兩部分：

1. 使用optional取代required

2. scalar最佳化

proto文件如下

message BigData {
         
        repeated MediumData mediumDatas = 1;
}
 
message MediumData {
         
        repeated SmallData smallDatas = 1; 
}
 
message SmallData {
        optional sfixed32 intValue = 1;
        optional fixed32 uintValue = 2;
        optional bool booleanValue = 3;
        optional float numberField = 4;
}

proto文件記載了BigData、MediumData及SmallData，SmallData只有基本資料型別，而MediumData及BigData則是用巢狀方式讓資料格式更大，repeated屬性可以讓欄位變成陣列（Array）或清單（List），由於直接使用ProtocolBuffer轉出來的類別轉AMF3的話，AMF3會把繼承的Message類一起寫入，為了避免這點，範例再寫一組同樣格式但沒有繼承的資料物件給AMF3使用，以求更客觀的比較結果

範例為測試AMF3及ProtocolBuffer的序列化及反序列化速度，結果如下

以大小來看，Protocol Buffer比較小，即使是巢狀資料也比AMF小一點，但速度方面是AMF3較好，原因可能是AMF3的序列化及反序列化為底層API，效能可能有被優化，不過以實用上來看Protocl Buffer的速度是可接受的，畢竟平常的封包也不會太大。

再來比較一下proto文件的required及optional差異，required是指示欄位一定要有值，而optional是可有可無，以官網的說法 ，required欄位如果之後要改成optional會有讀取問題，建議是使用optional，為了試驗，筆者把上述的smallData所有欄位改成required，比較一下效能，結果如下

如果是使用required，Protocol buffer的變化不大，筆者之前有試過optional加default的話，會比required欄位小很多，但如果都使用賦值，差異就看不出來了

另一個要測的是scalar，也就是欄位宣告的類型，Protocol Buffer跟AMF不同，即使類型同樣為正負號整數，必須依使用情況宣告成不同的scalar才能發揮Protocol Buffer最大功效，可參考 http://code.google.com/apis/protocolbuffers/docs/proto.html#scalar

也就是當使用整數時，如果是小值，可宣告成int，如果值常超過2²⁸，要用fixed32，或是整數常出現負號，應使用sint32，針對不同需求應宣告成對應類型，這部分就要看實例時，欄位要怎麼設計，筆者把範例修改成只宣告uint及int，比較一下兩者的差異

出乎意料的是差異不大，只有大小有明顯的變化，或許是筆者範例的欄位太少，只有一點的差異讓我有點意外。

最後做個總結，Protocol Buffer的測試似乎依實例來測會比較準，筆者目前寫的測試方法還是無法比較出差異，主要應該是值都是重覆使用，無法發揮封包特性，或許還要再想一個比較好的實例來測會比較準

原始檔下載

如果有網友測出不同結果，或覺得範例測試方法有誤，歡迎留言討論。

測試環境為： ProtocolBuffer 2.4.0a、Flex 4.0 SDK、Protoc-gen-as3 0.9.0、FlashPlayer 10.3 Release

相關文章： [教學]在Flash中使用Google Protocol Buffers

轉載請註明出處