tag:blogger.com,1999:blog-24611184.post4988909998268284008..comments2011-08-27T16:13:52.498-07:00Eishay Smithhttp://www.blogger.com/profile/09443096006184006852noreply@blogger.comBlogger17125tag:blogger.com,1999:blog-24611184.post-58722684773073409402011-04-16T05:51:20.741-07:002011-04-16T05:51:20.741-07:00Nice article , you have indeed covered topic in details with benchmarking result and graphics. <br /><br />Thanks<br />Javin<br /><a href="http://javarevisited.blogspot.com/2011/04/top-10-java-serialization-interview.html" rel="nofollow">Top 10 Java Serialization Interview Question </a>Javin Paulhttp://www.blogger.com/profile/15028902221295732276noreply@blogger.comtag:blogger.com,1999:blog-24611184.post-91196065861928182682011-01-22T21:15:35.495-08:002011-01-22T21:15:35.495-08:00http://harshcreationz.blogspot.com/2011/01/serialization-and-deserialization-from.html<br />Here you can deserialize object from another projectHarshahttp://www.blogger.com/profile/00683906560180928871noreply@blogger.comtag:blogger.com,1999:blog-24611184.post-50575416735022232042009-12-20T21:50:16.832-08:002009-12-20T21:50:16.832-08:00Thanks Ron!<br />&gt; I was however very surprised by the published results<br />In the project wiki I tried to emphasize that the sample set may be misleading and some serializers work better with some datasets and not others. See the maling list for more discussions about it. The data type (integer, floating point, characters, enums), their lengths and the data structures (single value, list, map) are very important when deciding on the serializer to use. At kaChing for example we have a pluggable serializer module and we switch between JSON and Protobuf according to the value types.<br /><br />&gt; I was also surprised to see that text serializers (xml, json) are better then hessian or java.<br />When dealing with small diverse data structure (mix of few strings and numerics) they are much better. Less so if you have a large list of the same type.<br /><br />&gt; I was wondering why not use an existing benchmark framework such as p-unit or japex.<br />No reason. Contributions for integration will be welcomed. <br /><br />&gt; I also think that each benchmark should be running in its own JVM, so as to make sure that all tests are run under the same conditions.<br />They do.<br /><br />&gt; I am not sure that the warm-up methods are enough.<br />Played with more warm-up time and this one was the optimal. Please let me know if you have better warm-up properties.<br /> <br />&gt; I hope these comments will help create a better benchmark.<br />They might, joining the project and contributing is more effective :-)Eishay Smithhttp://www.blogger.com/profile/09443096006184006852noreply@blogger.comtag:blogger.com,1999:blog-24611184.post-67965799392799689322009-12-20T21:20:48.151-08:002009-12-20T21:20:48.151-08:00Hi Ron! These are valid issues, and most are known to developers. And new contributions for improvements are happily accepted I think (I have contributed some additions, others too, it&#39;s a work in progress, as always).<br /><br />One thing that may help explain results is the small size of the test document -- this heavily penalizes implementations that have significant per-document overhead. Seems like this is the case for Hessian. I was also surprised to see its poor performance, as I too have benchmarked it to be quite fast on other tests. But on the other hand, PB and Thrift do quite well, so there is something odd with Hessian here (I contributed hessian driver so it should not have any obvious flaws -- but if there are, I would love to find them).<br /><br />Also: serializers for json, xml, are the fastest available. There are many implementations that are significantly slower; so another reason may be that perhaps some binary codecs are not quite as heavily optimized.<br /><br />At any rate I think that binary codecs would show better relative performance for larger documents. Default Java serialization possibly a little bit too; but that depends on ratio of class metadata to actual data (JDK serialization has to add per-class metadata for each included type -- when there are multiple instances, overhead is less).cowtowncoderhttp://www.blogger.com/profile/02343617472112278520noreply@blogger.comtag:blogger.com,1999:blog-24611184.post-73074524653113423202009-12-19T05:50:24.442-08:002009-12-19T05:50:24.442-08:00Hello,<br /><br />I have also written, but not publicized, a benchmark to test serialization. I found this project and I was however very surprised by the published results, which do not match mine.<br /><br />I was mostly interested in the differences between avro/reflection, java, hessian. I was also surprised to see that text serializers (xml, json) are better then hessian or java.<br /><br />Taking a look at the source. I was wondering why not use an existing benchmark framework such as p-unit or japex.<br /><br />I also think that each benchmark should be running in its own JVM, so as to make sure that all tests are run under the same conditions.<br />I am not sure that the warm-up methods are enough.<br /><br />The single test also includes the creation of the serializer. This does not take into account that serializers may have optimizations, so that the first call to the serializer will take much longer then subsequent calls.<br />So there should be tests for different use cases: <br /><br />- single serialize/deserialize (for example used in deep clone)<br />- single serializer/deserializer for multiple operations (for example used in client/server communication)<br />- etc... any suggestions ?<br /><br />The test is conducted with only one type of data. However different serializers excel in different domains. Some are better for graph structures, some for flat data, some depend on the length of the attribute names, package names etc., some optimize better with repeated objects, etc.<br /><br />The test does not differentiate between the features and requirements of the different serializers. Some require a schema or stub, some require code generation, some are schema tolerant, some require the transmission/storage of the schema etc.<br /><br />I hope these comments will help create a better benchmark.<br /><br />-- Ron<br />http://yajsw.sourceforge.netAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-24611184.post-6116235818451708482009-12-19T05:49:57.413-08:002009-12-19T05:49:57.413-08:00Hello,<br /><br />I have also written, but not publicized, a benchmark to test serialization. I found this project and I was however very surprised by the published results, which do not match mine.<br /><br />I was mostly interested in the differences between avro/reflection, java, hessian. I was also surprised to see that text serializers (xml, json) are better then hessian or java.<br /><br />Taking a look at the source. I was wondering why not use an existing benchmark framework such as p-unit or japex.<br /><br />I also think that each benchmark should be running in its own JVM, so as to make sure that all tests are run under the same conditions.<br />I am not sure that the warm-up methods are enough.<br /><br />The single test also includes the creation of the serializer. This does not take into account that serializers may have optimizations, so that the first call to the serializer will take much longer then subsequent calls.<br />So there should be tests for different use cases: <br /><br />- single serialize/deserialize (for example used in deep clone)<br />- single serializer/deserializer for multiple operations (for example used in client/server communication)<br />- etc... any suggestions ?<br /><br />The test is conducted with only one type of data. However different serializers excel in different domains. Some are better for graph structures, some for flat data, some depend on the length of the attribute names, package names etc., some optimize better with repeated objects, etc.<br /><br />The test does not differentiate between the features and requirements of the different serializers. Some require a schema or stub, some require code generation, some are schema tolerant, some require the transmission/storage of the schema etc.<br /><br />I hope these comments will help create a better benchmark.<br /><br />-- Ron<br />http://yajsw.sourceforge.netAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-24611184.post-67492983389130497172009-05-02T18:11:00.000-07:002009-05-02T18:11:00.000-07:00Thanks, I'll check it out once it'll be released!Eishay Smithhttp://www.blogger.com/profile/09443096006184006852noreply@blogger.comtag:blogger.com,1999:blog-24611184.post-76086662338792204862009-05-02T18:03:00.000-07:002009-05-02T18:03:00.000-07:00I assume you are using Binary Protocol for Thrift. If you try the newer Compact Protocol, it will serialize down probably as small as protobuf. <br /><br />Also, if you are using the released version of Thrift from sometime last year, the current trunk version (which is very stable, release coming soon!) has had a fair amount of performance work done on it.Bryan Duxburyhttp://www.blogger.com/profile/03943272906853855051noreply@blogger.comtag:blogger.com,1999:blog-24611184.post-67818156377109734702009-03-22T20:11:00.000-07:002009-03-22T20:11:00.000-07:00@cowtowncoder the main page is on the project&#39;s wiki at http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking?ts=1237772203&amp;updated=Benchmarking<BR/>Project commiters can update it and/or add more pages. For public discussion lets use the google group from now on at http://groups.google.com/group/java-serialization-benchmarking<BR/>Adding Hessian sounds like a good idea.Eishay Smithhttp://www.blogger.com/profile/09443096006184006852noreply@blogger.comtag:blogger.com,1999:blog-24611184.post-14064325984080402272009-03-22T20:01:00.000-07:002009-03-22T20:01:00.000-07:00Yes, separate page(s) make sense. Perhaps at the project page?<BR/><BR/>One more thing to possibly add: Hessian is one more simple thing to add, and something that is quite fast as well based on tests I did. It's a binary (java) object serialization protocol.<BR/>I could cobble a test together quite easily I think.<BR/><BR/>As to Cajo, I also do not quite see how that would fit. It seems like a big framework, and nothing suggest it uses a separate module serialization/deserialization component. From description I'd guess it could use plain old Java serialization.cowtowncoderhttp://www.blogger.com/profile/02343617472112278520noreply@blogger.comtag:blogger.com,1999:blog-24611184.post-28110353068940816252009-03-21T00:05:00.000-07:002009-03-21T00:05:00.000-07:00Cool! <BR/>I'll post the results in a dedicated page, its growing too big for this blog :-)Eishay Smithhttp://www.blogger.com/profile/09443096006184006852noreply@blogger.comtag:blogger.com,1999:blog-24611184.post-18869734713985678722009-03-20T23:31:00.000-07:002009-03-20T23:31:00.000-07:00I added some more tests; xml/stax with Aalto, as well as Fast Infoset (binary xml) via its stax api implementation.cowtowncoderhttp://www.blogger.com/profile/02343617472112278520noreply@blogger.comtag:blogger.com,1999:blog-24611184.post-3145517103212876952009-03-19T08:27:00.000-07:002009-03-19T08:27:00.000-07:00More results (with new lib)<BR/><BR/> , Object create, Serializaton, Deserialization, Serialized Size<BR/>java (externalizable) , 73.65100, 4683.54400, 14538.46300, 315<BR/>xstream(xpp) , 97.98270, 75685.54700, 135505.52950, 931<BR/>json , 87.99550, 2847.90250, 4306.42750, 310<BR/>protobuf , 189.38740, 3038.74250, 1979.13000, 217<BR/>xstream(stax) with conv , 87.61310, 9067.81750, 18113.96850, 325<BR/>java , 86.94640, 12254.38150, 57572.16250, 845<BR/>sbinary , 55.59485, 2846.53100, 2758.94450, 190<BR/>xstream(xpp) with conv , 87.63940, 10858.89200, 36172.06400, 310<BR/>thrift , 142.58605, 3683.40700, 3812.90900, 314<BR/>javolution xmlformat , 87.79790, 4487.80100, 10278.79150, 345<BR/>stax , 87.28780, 4323.57150, 7692.04550, 406<BR/>scala , 68.03025, 31674.93900, 150840.46500, 1950David Bernardhttp://www.blogger.com/profile/10258681071629942075noreply@blogger.comtag:blogger.com,1999:blog-24611184.post-84560836654903077902009-03-19T03:07:00.000-07:002009-03-19T03:07:00.000-07:00@eishay At it's core Cajo is about RPC, which means a lot of serialization/deserialization of object representations. I'm evaluating several remoting alternatives and your entry is very instrumental doing that.Ophirhttp://ophir.radnitz.name/noreply@blogger.comtag:blogger.com,1999:blog-24611184.post-90004279773318428472009-03-18T08:42:00.000-07:002009-03-18T08:42:00.000-07:00@ofir you are welcome to write the code and compare, though I don't see how is Cajo relevant to this benchmark.<BR/>@david i agree. One first need to see it serialization is a bottleneck at all. If its not and will never be then premature optimization is the source of all evil. If it is a bottleneck then the performance may vary a lot with different data sets (size, type etc.) and jvm profile.Eishay Smithhttp://www.blogger.com/profile/09443096006184006852noreply@blogger.comtag:blogger.com,1999:blog-24611184.post-59075492567550422262009-03-18T08:14:00.000-07:002009-03-18T08:14:00.000-07:00Just a quick note, result of the bench is important. But don't forget when you choose a technologie, the size of the code, developer need to write to serialize/deserialize "business" object (protobuf message aren't). If you have lot of message it could be a long task.David Bernardhttp://www.blogger.com/profile/10258681071629942075noreply@blogger.comtag:blogger.com,1999:blog-24611184.post-13827325846323761652009-03-18T06:48:00.000-07:002009-03-18T06:48:00.000-07:00Very interesting, thanks for the input. I'm wondering how Cajo (https://cajo.dev.java.net/) would compare.Ophirhttp://ophir.radnitz.name/noreply@blogger.com