本文作者:佚名

Google Protocol Buffers和java字符串处理控制

佚名 2019-04-19 201
摘要:大多数的操作码被从夜晚复制。懒得敲。直接在源代码和测试结果如下。serabuffer.proto档。使用下面的命令来生成java代码。protoc


大多数的操作码被从夜晚复制。懒得敲。

直接在源代码和测试结果如下。

serabuffer.proto档。使用下面的命令来生成java代码。

protoc -I=./ --java_out=./ serabuffer.proto


package Feinno.Practice.Learnoption java_package = Feinno.Practice.Learnoption java_outer_classname = ProtoBufferPracticemessage msgInfo  {  required int32 ID = 1  required int64 GoodID = 2  required string Url = 3  required string Guid = 4  required string Type = 5  required int32 Order = 6}

以下是java部分代码。直接输出结果,要測试不同字符串长度的,能够直接替换当中的字符串然后run就可以。

package Feinno.Practice.Learnimport com.google.protobuf.ByteStringpublic class Test{    public byte[] serialize()    {        ProtoBufferPractice.msgInfo.Builder builder=ProtoBufferPractice.msgInfo.newBuilder()          builder.setGoodID(100)          builder.setGuid(11111-23222-3333-444)          builder.setOrder(0)          builder.setType(及基于消息的协调机制不适合在某些应用中使用,因此须要有一种可靠的、可扩展的、分布式的、可配置的协调机制来统一系统的状态)          builder.setID(10)          builder.setUrl(http://www.gufensoso.com/search/?q=java+protocol+buffer)          ProtoBufferPractice.msgInfo info=builder.build()                byte[] result=info.toByteArray()           return result    }        public void deserialize(ByteString result)    {        try{              ProtoBufferPractice.msgInfo msg = ProtoBufferPractice.msgInfo.parseFrom(result)  //            System.out.println(msg)          }          catch(Exception ex){              System.out.println(ex.getMessage())          }    }        public static void main(String[] args)     {        Test t=new Test()        long s1=System.nanoTime()        byte[] b = t.serialize()        long s2=System.nanoTime()                System.out.println(序列化后长度是:+b.length+ 耗时:+(s2-s1))                 long a1=System.nanoTime()          t.deserialize(ByteString.copyFrom(b))        long a2=System.nanoTime()          System.out.println(反序列化耗时:+(a2-a1))                 long s3=System.nanoTime()                StringBuilder sb=new StringBuilder()        sb.append(Ã).append(100).append(Ã).append(11111-23222-3333-444).append(Ã).append(0).append(Ã).append(及基于消息的协调机制不适合在某些应用中使用,因此须要有一种可靠的、可扩展的、分布式的、可配置的协调机制来统一系统的状态).append(Ã).append(10).append(Ã).append(http://xxx.jpg)        byte[] c=sb.toString().getBytes()        long s4=System.nanoTime()                System.out.println(拼接字符后长度:+c.length+ 耗时:+(s4-s3))        long c1=System.nanoTime()         sb.toString().split(Ã)        long c2=System.nanoTime()         System.out.println(拆字符串耗时:+(c2-c1))                     }}

1、字符串长度较短时:
序列化后长度是:50 耗时:32115919
拼接字符后长度:56 耗时:36223
反序列化耗时:2484294
拆字符串耗时:305783

2、字符串长度较长时,也就是如今代码中的。


序列化后长度是:265 耗时:20092297
拼接字符后长度:229 耗时:48297
反序列化耗时:2445656
拆字符串耗时:354683

3、字符串长度再加长时
序列化后长度是:435 耗时:26542406
拼接字符后长度:398 耗时:53127
反序列化耗时:5412019
拆字符串耗时:527950

结果:
1、速度方面,拼接字符串速度是序列化的500-1000倍。拆分字符串是反序列化的8倍左右。
2、大小方面。数据小的序列化的体积小,数据大了以后,字符串拼接有优势;
3、上面结果数据事实上是不固定的,和详细的数据有关。


结论:

网上的资料显示。protocol buffer在序列化方面无论提交还是性能方面都是非常优秀的,可是这里的測试结果显示和字符串处理方式来比差距就太明显了。

不要迷信,须要自己測试过才有体会,有些场景。用字符串处理的方式比序列化的方式更有优势。消息中间件假设用字符串的方式来处理。性能应该成倍增加。



版权声明:本文博主原创文章,博客,未经同意不得转载。

未经允许不得转载:

作者:佚名,标题:Google Protocol Buffers和java字符串处理控制,原文地址:https://www.vfjianzhan.com/donot/77145.html发布于2019-04-19
转载或复制请以超链接形式并注明出处DESTOON

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏