tag:blogger.com,1999:blog-7188290487158961538.post5360411139470425693..comments2015-11-09T14:37:52.108+08:00Comments on Water and Bread: ProtocolBuffer VS AMF3(fixed)GDhttp://www.blogger.com/profile/01802338680303841518noreply@blogger.comBlogger11125tag:blogger.com,1999:blog-7188290487158961538.post-88376275368463236602011-06-03T01:05:54.525+08:002011-06-03T01:05:54.525+08:00嗯,您說的沒錯,會造成差異的因素應該盡量避免,我已更新release版的結果上去嗯,您說的沒錯,會造成差異的因素應該盡量避免,我已更新release版的結果上去GDhttps://www.blogger.com/profile/01802338680303841518noreply@blogger.comtag:blogger.com,1999:blog-7188290487158961538.post-48010808331193691602011-06-02T22:50:16.425+08:002011-06-02T22:50:16.425+08:00但不管怎样,debugger版的Flash Player会大大降低ActionScript执行效率。...但不管怎样,debugger版的Flash Player会大大降低ActionScript执行效率。用debugger版测出来的数据没有参考价值。Atryhttps://www.blogger.com/profile/15788733189393255037noreply@blogger.comtag:blogger.com,1999:blog-7188290487158961538.post-34993766264717672512011-06-02T22:47:18.288+08:002011-06-02T22:47:18.288+08:00測試的部分還要再設計,這次測試主要是測大數據,且沒有測平均數,改良的做法或許可以參考你貼的網站測試的部分還要再設計,這次測試主要是測大數據,且沒有測平均數,改良的做法或許可以參考你貼的網站GDhttps://www.blogger.com/profile/01802338680303841518noreply@blogger.comtag:blogger.com,1999:blog-7188290487158961538.post-81833351803768211272011-06-02T17:23:08.525+08:002011-06-02T17:23:08.525+08:00有个老外也做过AMF和protobuf的性能比较,他用的是较早的protoc-gen-as3,性能比...有个老外也做过AMF和protobuf的性能比较,他用的是较早的protoc-gen-as3,性能比 0.9.x 稍差一点。<br /><br />http://backgroundthinking.wordpress.com/2010/05/24/performance-of-google%E2%80%99s-protocol-buffers-in-flex-redux/<br /><br />这个老外没贴代码,不知道他用的什么数据,但估计他填的数据中有许多小整数。在小整数很多的情况下,protobuf格式比AMF会小得多。他的测试结果可以体现这一点。Atryhttps://www.blogger.com/profile/15788733189393255037noreply@blogger.comtag:blogger.com,1999:blog-7188290487158961538.post-17950082168928872892011-06-02T17:15:33.284+08:002011-06-02T17:15:33.284+08:00抛开optional字段留空以及小整数不论,目前您的测试代码如果在非debugger的Flash P...抛开optional字段留空以及小整数不论,目前您的测试代码如果在非debugger的Flash Player上跑,性能也不会有这么大差距。这是我跑出来的结果:<br /><br /><br />[PROTOCOL BUFFERS]<br /> serialization<br /> small:<br /> size = 18b, cost = 0ms<br /> medium:<br /> size = 9.77kb, cost = 1ms<br /> big:<br /> size = 97.7kb, cost = 12ms<br /><br /> deserialization<br /> small:<br /> cost = 0ms<br /> medium:<br /> cost = 1ms<br /> big:<br /> cost = 11ms<br /><br />[AMF3]<br /> serialization<br /> small:<br /> size = 90b, cost = 0ms<br /> medium:<br /> size = 12.8kb, cost = 0ms<br /> big:<br /> size = 127kb, cost = 10ms<br /><br /> deserialization<br /> small:<br /> cost = 0ms<br /> medium:<br /> cost = 1ms<br /> big:<br /> cost = 7ms<br /><br />Total Memory = 4.41mbAtryhttps://www.blogger.com/profile/15788733189393255037noreply@blogger.comtag:blogger.com,1999:blog-7188290487158961538.post-82079622177109136412011-06-02T17:10:35.271+08:002011-06-02T17:10:35.271+08:00此外,您的测试仍然没有体现optional字段留空不填的情形,也没有测试小整数(RIA应用中最常见的...此外,您的测试仍然没有体现optional字段留空不填的情形,也没有测试小整数(RIA应用中最常见的数据)的性能。Atryhttps://www.blogger.com/profile/15788733189393255037noreply@blogger.comtag:blogger.com,1999:blog-7188290487158961538.post-34090594939418700002011-06-02T17:08:16.092+08:002011-06-02T17:08:16.092+08:00你的测试数据用的是Debugger版本的Flash Player,对解释执行的protobuf很不公...你的测试数据用的是Debugger版本的Flash Player,对解释执行的protobuf很不公平。因为Protobuf的序列化/反序列化代码是在解释器中执行的,性能受Flash Player版本影响很大;而AMF则是调用了C++库,性能与Flash Player版本关系不大。<br /><br />我自己用最新的Flash Player 10.3非Debugger版测试,Protobuf并不比AMF慢很多,二者性能在同一数量级。Atryhttps://www.blogger.com/profile/15788733189393255037noreply@blogger.comtag:blogger.com,1999:blog-7188290487158961538.post-90997113347889867272011-05-26T21:55:04.145+08:002011-05-26T21:55:04.145+08:00Atry感謝您的回應,很高興能有機會跟您討論,這次的範例在測試上確實沒考慮到實際的使用情形,數值及欄...Atry感謝您的回應,很高興能有機會跟您討論,這次的範例在測試上確實沒考慮到實際的使用情形,數值及欄位的設計的確有誤,我會參考您的意見再改寫一版測試,也希望您能繼續給予批評與指教,謝謝GDhttps://www.blogger.com/profile/01802338680303841518noreply@blogger.comtag:blogger.com,1999:blog-7188290487158961538.post-82319665712985980262011-05-26T21:23:31.892+08:002011-05-26T21:23:31.892+08:00还有,全部测试数据都是些重复数据,对这些重复数据测试压缩率,当然会超级高了,说明不了任何问题。还有,全部测试数据都是些重复数据,对这些重复数据测试压缩率,当然会超级高了,说明不了任何问题。Atryhttps://www.blogger.com/profile/15788733189393255037noreply@blogger.comtag:blogger.com,1999:blog-7188290487158961538.post-54421238675811533622011-05-26T21:13:36.142+08:002011-05-26T21:13:36.142+08:00此外,字符串和字节数组的字段可以去掉。大的字符串和字节数组不论用何种格式都是简单的字节拷贝,不会有太...此外,字符串和字节数组的字段可以去掉。大的字符串和字节数组不论用何种格式都是简单的字节拷贝,不会有太大的性能差异。Atryhttps://www.blogger.com/profile/15788733189393255037noreply@blogger.comtag:blogger.com,1999:blog-7188290487158961538.post-39505646064238438582011-05-26T21:11:39.772+08:002011-05-26T21:11:39.772+08:00测试用例全错!!!!!
1. required应慎用。参见 http://code.google....测试用例全错!!!!!<br /><br />1. required应慎用。参见 http://code.google.com/apis/protocolbuffers/docs/proto.html 中的“Required Is Forever”一段。试试把proto文件中的required改成optional再测测性能,有惊喜。<br /><br />2. default选项应该同optional一起用而不是和required一起用。参见 http://code.google.com/apis/protocolbuffers/docs/proto.html#optional 。<br /><br />3. 重复出现相同的长字符串是一种实践中根本不可能出现的情况,偏偏AMF对这种情况有优化,这不公平。考虑AMF3一个small包就有157B,包含了500个small的medium包竟然才14.8KB,还不到small的一百倍。<br /><br />4. uint32类型适合出现小数字几率高的情形。0xFFFFFF用uint32类型存取很低效,应该用fixed32。参见 http://code.google.com/apis/protocolbuffers/docs/proto.html#scalar<br /><br />5. int32类型适合出现小正数几率高的情形。2147483647用int32类型存取很低效,应该用sfixed32。<br /><br />总之,这样的测试应该尽量用接近实践中的数据。实践中应该有一定比例采用默认值而不设置值的。随机生成的数据也要考虑实践中的分布情况。实践中除了某些UUID外,别的数据很少是均匀分布在0到0xFFFFFFFF之间的而是集中在小数字的情形上。<br /><br />实践中最常见的数据包往往内容不大,最多上百字节,但格式异常复杂,嵌套层次很多,此外还存在大量小整数。这类数据正好是Protobuf专门优化的类型。Atryhttps://www.blogger.com/profile/15788733189393255037noreply@blogger.com