测试了一下编解码的执行效果
背景
在《程序媛的人生观》这篇文章中，在博客园有热心朋友反馈：
SRE实战 互联网时代守护先锋，助力企业售后服务体系运筹帷幄！一键直达领取阿里云限量特价优惠。protosbuff支持的类型少~而且不支持嵌套~性能更没有json高，如不是外网使用节约流量，没有用的必要~
我觉得评论说的很好。但是以淘金式思路来看这个问题，需要提出自己的问题，进行批判性吸收。
编码效率
写了一段代码测试使用protostuff和json两种序列化编码的执行速度。结果每次protostuff的速度都比json快。下面是其中3次的结果：
（结果1）
（结果2）
（结果3）
结论：protostuff编码速度快于json。
这个数据让我非常的自责，因为可以看到编码的速度在100ms上下，是非常耗时的操作。但是我在编写我们项目代码的时候没有加专门的监控统计。
为了验证是否和执行顺序有关，调换一下执行顺序。实际上如果在同一个方法里先后运行两次序列化，会影响执行结果。但是因为用了两个独立的junit test方法，所以影响可忽略不计。来看看效果。
这是修改了顺序的代码。下面是其中3次的结果：
（结果1）
（结果2）
（结果3）
可以看到，protostuff编码速度仍然快于json。
解码效率
改造一下代码，测试一下解码效率。
（结果1）
（结果2）
（结果3）
结论：protostuff解码速度远远快于json。
编码后的大小
结果：
结论：protostuff编码后的数据小于json。
换一个复杂对象验证效果：
结果：
又换了一个更复杂的，结果：
虽然protostuff编码后的数据小于json。但是相差不是很大。这是因为刚才所有的测试（包括效率和大小）都是基于我将protostuff编解码和base64绑定处理了。
这是编码。
这是解码。如果不用base64，最后一条的结果是
protostuff的优势还是很明显的。
关于支持的类型少和不支持嵌套。看上面我用到的对象Pod，是
io.fabric8.kubernetes.api.model.Pod，有k8s背景的朋友应该知道这个对象有多复杂。测试里面的ResourceMessage对象其实是个泛型对象，里面嵌套了Pod。所以也不存在不支持嵌套这一说。
思考
虞美人
上中学的时候，家里养了一盆花死掉了。花盆放在阳台外面，土里长了草。我心里觉得不公平。为什么花要在花盆里收到精心的呵护，而普通的小草就要被拔掉呢？于是，我每天给小草浇水。
奇迹出现了，花盆里长出花来。大红色的花，我见过的最完美的花。
之前在妈妈办公室后面有个小花园，里面长满了月季花。都是比我还高的月季花树，不是普通路边见到的矮矮的。但是我试图找到一朵完美的花却找不出来。仔细看花瓣，都是有瑕疵的。
之前我喜欢白色、黄色、粉色这些颜色淡雅的花。但是自从看到这朵花，我甚至喜欢穿红色的衣服，虽然红色并不合适我。后来想查查那究竟是什么花。找到长得最像的是虞美人。但是我的花其他部分像草，花要红的纯粹。我的花要美得多。更像是草的精灵。
做自己想做的事情，用心去做。不苛求奇迹，但是有一天奇迹会找到你。
语音版点击《测试了一下编解码的执行效果》获取，用耳朵来听姿势~~
推荐阅读
