偶看新闻你算什么男人钢琴简谱:java 各种序列化机制的性能比较
来源：百度文库 编辑：偶看新闻 时间：2024/04/28 09:52:52
We moved to a new home
The wiki moved to http://wiki.github.com/eishay/jvm-serializers/
For discussions please use http://groups.google.com/group/java-serialization-benchmarking
Intro
Started with few blog posts and with the help of many contributes, this project is now benchmarking much more then just protobuf and thrift. Thanks to all who looked at the code, contributed, suggested and pointed bugs. Three major contributions are from cowtowncoder who fixed the stax code, Chris Pettitt who added the json code and David Bernard for the xstream and java externalizable. The charts below are displaying the latest results. Note that the charts are scaled to best fit the results and they might be misleading in come cases. If you wish to see the numbers scroll down to the chart at the end of the page. Overall we have benchmarks for protobuf, thrift, java, scala, few implementations of stax, binaryxml, json, xstream, javolution, hessian, avro, sbinary, JSON Marshaller, and Kryo.
Numbers are not everything
Benchmarks can be very misleading. Different hardware, use cases, and/or datasets will provide different results and sometimes a marginal performance boost is eclipsed by other features like forward and backward compatibility, cross language support, simpler API, and more.
Charts
Setup
The following measurements were performed with revision r128 on Windows 7 64-bit using Sun's JVM 1.6.0_15 JRE 32-bit, with an Intel Core i7 920 CPU. Note the tests are run with a JVM heap size of 16MB and using the server HotSpot compiler.
Omitted from the first three charts: json/google-gson and scala. These serializers are so slow, they would break the scale of our charts. See below for the naked data.
Total Time
Including creating an object, serializing and deserializing:
Serialization Time
Serializing with a new object each time (object creation time included):
Deserialization Time
Often the most expensive operation. To make a fair comparison, all fields of the deserialized instances are accessed - this forces lazy deserializers to really do their work. The raw data below shows additional measurements for deserialization.
Serialization Size
May vary a lot depending on number of repetitions in lists, usage of number compacting in protobuf, strings vs numerics, assumptions that can be made about the object graph, and more. Interesting point is Scala and Java which holds the name of the classes in the serialized form. I.e. longer class names = larger serialized form. In Scala its worse since the Scala compiler creates more implicit classes then java.
Object Creation Time
Object creation is not so meaningful since it takes in average 100 nano to create an object. The surprise comes from protobuf which takes a very long time to create an object. Its the only point in this set of benchmarks where it didn't perform as well as thrift. Scala (and to a lesser point - java) on the other hand is fast, seems like its a good language to handle in memory data structures but when coming to serialization you might want to check the alternatives.
Numbers
Times are in nanoseconds, sizes are in bytes.
, Object create, Serialize, /w Same Object, Deserialize, and Check Media, and Check All, Total Time, Serialized SizeComment by daru...@gmail.com, Mar 22, 2009
avro-generic , 4024.12346, 8018.86600, 4030.37150, 4779.31000, 4779.31000, 4779.31000, 12798.17600, 211
avro-specific , 2643.18237, 5749.96650, 3204.01250, 4355.65650, 4355.65650, 4355.65650, 10105.62300, 211
activemq protobuf , 254.11328, 6777.68650, 71.48850, 14.60200, 2574.77900, 4924.94600, 11702.63250, 231
protobuf , 470.51276, 7226.50900, 3698.94400, 3478.95350, 3826.13550, 4371.60450, 11598.11350, 231
thrift , 227.97550, 7302.97850, 7165.79000, 7948.73750, 7948.73750, 7948.73750, 15251.71600, 353
hessian , 168.21827, 13354.78550, 12849.28050, 21082.57000, 21082.57000, 21082.57000, 34437.35550, 526
kryo , 169.04829, 3437.83750, 3297.00450, 4308.20000, 4308.20000, 4308.20000, 7746.03750, 226
kryo-optimized , 170.10886, 2912.73750, 2813.59000, 3998.48150, 3998.48150, 3998.48150, 6911.21900, 207
java , 168.80043, 25773.30650, 25136.38350, 71573.79650, 71573.79650, 71573.79650, 97347.10300, 919
java (externalizable) , 170.74098, 2874.11850, 2674.87900, 3043.00350, 3043.00350, 3043.00350, 5917.12200, 264
scala , 125.51285, 62838.27450, 61814.38950, 194495.92550, 194495.92550, 194495.92550, 257334.20000, 2024
json (jackson) , 175.75949, 7223.81900, 7113.92050, 6084.47000, 6084.47000, 6084.47000, 13308.28900, 378
json/jackson-databind , 173.56918, 10550.41150, 10443.20400, 10575.58100, 10575.58100, 10575.58100, 21125.99250, 465
JsonMarshaller , 171.88033, 24618.39500, 24488.50800, 41115.13300, 41115.13300, 41115.13300, 65733.52800, 370
protostuff-json , 475.75992, 8639.84000, 8069.39750, 7366.95850, 7366.95850, 7366.95850, 16006.79850, 448
protostuff-numeric-json , 479.06845, 8011.94950, 7405.96250, 7185.39250, 7185.39250, 7185.39250, 15197.34200, 359
json/google-gson , 173.28482, 449118.35900, 449995.44750, 491268.32050, 491268.32050, 491268.32050, 940386.67950, 470
stax/woodstox , 173.08692, 8542.42850, 8408.70150, 12161.06250, 12161.06250, 12161.06250, 20703.49100, 475
stax/aalto , 173.82471, 6330.78500, 6159.79150, 8082.84650, 8082.84650, 8082.84650, 14413.63150, 475
binaryxml/FI , 174.39919, 15336.63850, 15210.98450, 14528.33450, 14528.33450, 14528.33450, 29864.97300, 300
xstream (stax with conv), 174.35308, 16116.89100, 15564.12000, 26235.77100, 26235.77100, 26235.77100, 42352.66200, 399
javolution xmlformat , 175.25803, 7584.83750, 7446.11950, 10567.31900, 10567.31900, 10567.31900, 18152.15650, 419
sbinary , 126.19877, 8704.78100, 8743.20950, 4584.87150, 4584.87150, 4584.87150, 13289.65250, 264
Great stuff. A couple of quick nit-pick items (I'd happily fix but I don't have wiki edit permissions):
- Would be good to indicate the axis on the graphs, if only to say whether longer bars are better or worse. - Also might be useful to break up the graphs with a horizontal line or something, it's hard to tell whether the text goes with graph above or below it. - "Tree major contributions" => "Three major contributions" - "May very a lot" => "May vary a lot"
Comment by project member tsaloranta@gmail.com, Mar 23, 2009One minor comment (which I can help with): perhaps also simple sum of deser + ser, since oftentimes this is the overall time taken, either by one side of conversatio n (server or client) or by both combined.
I have also noticed that results vary a lot between different machines, my older home workstation giving totally different numbers from work machine.
Comment by project member david.bernard.31, Mar 24, 2009I did some change (for other result)
optimise Xpp to generate compactXml instead of Pretty/indented allow XStream to select the implementation of Stax (use Woodstox by default) fix label of xstream configuration
Comment by jos...@gmail.com, Mar 25, 2009Would be nice if you compare against the optimize-for-speed version of protobuf, which is not the default.
Comment by project member david.bernard.31, Mar 26, 2009results from protobuf are with "optimize-for speed".
use the mailing-list/group
Comment by tmnich...@gmail.com, Mar 27, 2009I'd love to see how Hessian (http://hessian.caucho.com/) and Ice (http://www.zeroc.com/ice.html) stack up here. Awesome work guys.
Comment by project member tsaloranta@gmail.com, Mar 31, 2009Joselo: "optimize-for-speed" is on. Without it, PB is much slower (for me, 3x).
tmnichols: I can add Hessian, should be simple (done it before)
One minor change: I removed 10x multiplier for object creation, otherwise it'll skew results (since you don't create 10 instances, serializer just one). I think it was originally just used to make run time long enough.
Comment by project member tsaloranta@gmail.com, Mar 31, 2009Due to change in object creation, here's numbers I get on my work station, for reference (eishay can update 'official' results too):
, Object create, Serialization, Deserialization, Total Time, Serialized SizeComment by project member tsaloranta@gmail.com, Apr 1, 2009
protobuf , 59.19145, 537.94075, 294.13640, 891.26860, 217
thrift , 52.96210, 494.54925, 522.01160, 1069.52295, 314
java , 48.08995, 1736.61825, 7258.44035, 9043.14855, 845
java (externalizable) , 46.87810, 690.94225, 1870.71525, 2608.53560, 315
scala , 45.36270, 4018.60430, 19122.84775, 23186.81475, 1950
stax/woodstox , 48.64915, 751.47950, 1018.75335, 1818.88200, 406
stax/aalto , 48.75460, 543.86225, 785.45220, 1378.06905, 406
binaryxml/FI , 48.73490, 1550.54480, 1537.80335, 3137.08305, 224
json (jackson) , 48.67715, 382.99400, 593.11015, 1024.78130, 310
xstream (xpp) , 48.57065, 9741.56200, 17444.81985, 27234.95250, 759
xstream (xpp with conv) , 48.66520, 1704.66610, 5507.66675, 7260.99805, 287
xstream (stax) , 48.84445, 9799.39625, 15580.16955, 25428.41025, 797
xstream (stax with conv), 48.62815, 1440.40925, 2615.74715, 4104.78455, 325
javolution xmlformat , 48.96825, 535.32845, 1315.22985, 1899.52655, 345
sbinary , 45.05305, 406.14195, 386.88480, 838.07980, 190
Hmmh. I think Xstream(stax) has something funny going on, since serialized size differs from that of Xstream(xpp). Perhaps name aliasing is not done with stax? Otherwise sizes should be the same.
One more thing: it would be great if during warmup roundtrip checking was done: start with object, serialize, deserialize, verify that results match. This to ensure ser/deser are not broken -- while serialized size gives some indication, it's not reliable test.
Comment by arnieg0...@gmail.com, Apr 6, 2009for Java VM based tests, it'd be helpful if you mention which version of the JDK. There seems to be a big difference between 1.5 and 1.6
Comment by project member eis...@gmail.com, Apr 8, 2009Sorry for late response, didn't get notifications on the comments. In the future please comment on the project mailing list.
@darugar thanks! fixed
@tsaloranta isn't it the "Total Time" ?
@joselo we are using optimize for speed in this benchmark. The difference is very large, check out this post for more info: http://www.eishay.com/2008/11/protobuf-with-option-optimize-for-speed.html
@tmnichols contributions are happily accepted, shoot me an email or tweet @eishay if you have some time to work on it
@tsaloranta very interesting, I'll check it out when I'll have some time. protobuf seems to be now faster then json, I know some people who will be delighted :-)
@arnieg0001 we used java6 but note that the results are not absolute but a comparison. I guess (though need to verify) that the jvm version should effect them proportionally.
Comment by openco...@gmail.com, Apr 16, 2009Please include also memory usage. Very often it is possible to serialize 1 GB of object structures, but deserialization will fail with OutOfMemory? or simular exception.
Comment by project member eis...@gmail.com, Apr 16, 2009That's a bit hard to do. Any suggestions?
Comment by project member tsaloranta@gmail.com, Apr 16, 2009Memory usage measurementis non-trivial, but more importantly I am not sure I see the point. Why? Because most impls (and all fast ones) are effectively streaming/chunking, so the only thing retained in memory are the business objects (result or input). And those should have about the same size.
That could expose some flaws/suboptimalities in implementations, perhaps that would be the point? And others would work up until point where memory is used by "legitimate" objects.
Comment by stinkymi...@gmail.com, Apr 17, 2009The number is in 'nanosecond' but I see the following in the code
return iterationTime(delta) / 10d;
So, the numbers are scaled wrong???
Comment by project member eis...@gmail.com, Apr 18, 2009Thanks @stinkyminky, you are right, there was a merge clobber which left behind some buggy code. Fixing it and loading the correct data withthe latest results from @tsaloranta additional serializer code.
Comment by chad_wal...@yahoo.com, May 12, 2009Eishay, thanks for putting these benchmarks together. I do some work on Thrift and I am looking into the benchmarks to understand some things that don't quite fit.
I posted a bit of a report and some follow-up to the thrift-dev mailing list.
http://mail-archives.apache.org/mod_mbox/incubator-thrift-dev/200905.mbox/%3CC62E9622.97C4C%25cwalter@microsoft.com%3E
You can see more follow-up on the rest of the mailing list archives there too -- just look for posts with the title "Report on thrift-protobuf-compare" in http://mail-archives.apache.org/mod_mbox/incubator-thrift-dev/200905.mbox/thread
The main upshot is that: 1. You should update to a more recent version of Thrift and use TCompactProtocol 2. The API you have chosen around byte puts Thrift at a bit of disadvantage since it doesn't support that directly. Also, the way that you serialize once and then deserialize 10000 times doesn't fit well with Thrift's transport models, which are more designed for real world RPC cases. 3. By making some fairly minor modifications to Thrift and the benchmark program, I was able to get Thrift to perform at roughly the same level as protocol buffers, albeit with some modest room for improvement on deserialization that I am still investigating 4. The biggest issue is that the dynamic serializations are not being tested in a manner that gives a true apples-to-apples comparison with Thrift, protocol buffers, and other statically generated systems. This makes Thrift and protocol buffers look like they perform no better or even worse than, say, JSON, but this is not an accurate reflection of the underlying realities because the JSON serialization and deserialization implementations are not actually correct. You can see this by adding another person to the list in StdMediaSerializer?::create(). I am happy to discuss further.
Let's chat more about this and see if there are ways to get an accurate picture of the benchmarks that puts each implementation in its best possible light without compromising correctness.
Cheers,
Chad
Comment by project member eis...@gmail.com, May 12, 2009Hi Chad,
That's an awesome feedback, thanks!
There are indeed few things we need to fix, some are obvious like the URLs in the java std serializer and some are less like the way dynamic serializers are handling lists (a good point which I totally agree on). I also agree we should exploit the serializers as much as possible for best performance, but without being unfair to the other serializers. Since you invested so much in it, I hope you could help me a bit more. Could you please start a discussion in the project's group and cross link it with the one at the thrift-dev list? As for fixing / enhancing the code, right now I am a bit overloaded but I promise to work on it when I'll have time. Could you please post appropriate bugs? Or even better, if you have the time and will take the oath of being fair to other serializers then I'll be happy to make you a committer.
As a side note, usage patterns and data set may have a huge effect of any of the serializers performances. Given that, the code samples of how do the APIs looks like and how to use them correctly might be more valuable them the numbers in the wiki.
Comment by chad_wal...@yahoo.com, May 12, 2009Eishay, let me look into what is feasible in terms of time commitment and also code contribution. I can certainly file some bugs and propose some enhancements.
Comment by chad_wal...@yahoo.com, May 13, 2009I added two issues. Issue #4 is much much more significant. The way things are currently is giving people the incorrect perception that, say, "json performs as well or better than protocol buffers and Thrift". However, the benchmarks only show this because the json implementation is not doing a proper serialization and deserialization. Just because you can write one object into a string and then read that string back to produce the same object does not mean that you have a proper implementation of serialization and deserialization -- you need to be able to do the same for a variety of similar objects and many of these implementations do not stand up under what should be non-material changes to the input object.
Comment by project member eis...@gmail.com, May 13, 2009Thanks Chad!
Comment by project member tsaloranta@gmail.com, Jun 24, 2009FWIW, I improved json and stax/xml serializers to resolve issue #4 regarding these serializers. Same could and should be done for other serializers that have the issue. For me the numbers didn't seem to change a lot, but it'd be good to run 'official' numbers using same setup as with earlier published numbers.
Comment by project member eis...@gmail.com, Jun 29, 2009Updated the page with latest results (using Java6), added the new serializers.
Comment by maitai.t...@gmail.com, Jun 30, 2009Hello,
Where can I download the source for those performance tests?
Thanks Tai
Comment by project member eis...@gmail.com, Jun 30, 2009Sure, go to: http://code.google.com/p/thrift-protobuf-compare/source/checkout
Comment by project member eis...@gmail.com, Aug 4, 2009Added JsonMarshaller? serializer (by Pascal-Louis Perez) results http://code.google.com/p/jsonmarshaller/
Comment by project member nathan.s...@gmail.com, Sep 28, 2009Added Kryo results: http://code.google.com/p/kryo/ Updated the page to latest results, which include some bug fixes important to accurate comparison. Also sorted the charts from smallest to largest, since smaller is always better this makes it easier to compare.
Comment by gmike....@gmail.com, Nov 24, 2009The charts and numbers at the head of this page are more recent than the numbers in the March 31 post by tsaloranta, right? Some of the numbers are very different!
I downloaded and tried this recently. It would not compile as is, I had to change ThriftSerializer?.java to import from org.apache.thrift rather than com.facebook.thrift (well, first I had to install apache thrift because I got a whole lot more compilation errors if I used the libthrift.jar that came with this benchmark). I also had a problem with the lines of ThriftSerializer?.java where it invokes the big constructor of Image --- which does not exist in the code that my installation of thrift generated. Have I missed something?
Thanks, Mike
Comment by mabing...@gmail.com, Dec 11, 2009I added hprose benchmarking:
, Object create, Serialization, Deserialization, Total Time, Serialized Size
hprose property mode , 208.19696, 15773.10750, 16377.67900, 32358.98346, 533
hprose field mode , 205.41509, 23499.67650, 19662.78150, 43367.87309, 522
hprose , 203.30761, 4094.55700, 4330.77800, 8628.64261, 219
protobuf , 350.66806, 3547.89550, 2004.12100, 5902.68456, 231
thrift , 264.43733, 4101.33800, 3781.55100, 8147.32633, 353
hessian , 205.94288, 339238.91750, 43325.37500, 382770.23538, 541
kryo , 205.38027, 3535.06750, 2243.45750, 5983.90526, 236
kryo-optimized , 202.22821, 3276.48900, 2133.31850, 5612.03571, 217
java , 201.89101, 12753.18150, 56162.67250, 69117.74501, 919
java (externalizable) , 201.38155, 5654.45850, 15510.31400, 21366.15405, 397
WARN: serializer 'scala' failed round-trip test (ser+deser produces Object different from input), input=serializers.scala.MediaContent@64874d73, output=serializers.scala.MediaContent@3c5d6af4
scala , 141.18095, 30504.57100, 147533.80950, 178179.56145, 2024
json (jackson) , 202.95758, 2825.48800, 3986.98400, 7015.42958, 378
json/jackson-databind , 201.83787, 4683.36850, 6100.69450, 10985.90087, 465
JsonMarshaller , 203.79324, 11755.51900, 20995.25800, 32954.57024, 448
protostuff-json , 351.74195, 3190.72350, 5442.42800, 8984.89345, 448
protostuff-numeric-json , 346.12873, 2942.77400, 4889.71850, 8178.62123, 359
json/google-gson , 205.73946, 286707.15700, 334304.30100, 621217.19745, 470
stax/woodstox , 202.68270, 5899.47550, 9202.35400, 15304.51220, 475
stax/aalto , 207.46392, 4699.86200, 5960.31750, 10867.64342, 475
binaryxml/FI , 206.75105, 11533.04250, 14486.07900, 26225.87255, 300
xstream (stax with conv), 208.10167, 11326.87650, 19388.07600, 30923.05417, 399
javolution xmlformat , 205.25015, 5481.46200, 8320.14500, 14006.85715, 419
WARN: serializer 'sbinary' failed round-trip test (ser+deser produces Object different from input), input=serializers.scala.MediaContent@2a0b6efa, output=serializers.scala.MediaContent@54a2f4a6
sbinary , 145.60849, 3479.90650, 2419.75250, 6045.26749, 264
@mabingyao: Thanks, looks interesting. Would you like to share it with us? @Mike: Sorry, I'm not aware of the problem. You are welcome to help fixing it. Please send me an email if you want to contribute (eishay at gmail)
Comment by dsy...@gmail.com, Dec 29, 2009Hi guys, I use protobuf but I fail to get the good performance listed here. After serialization, the size is 118 bytes and the serialization takes approx. 350 microseconds. I use Java version of protobuf and my computer is Xeon 1.6 quad core processor on XP. Can someone give me a hand here?
Comment by project member eis...@gmail.com, Dec 29, 2009How can we help?
Comment by jerda...@speakeasy.net, Feb 2, 2010Awesome! Extremely useful!. You might also add: java.beans.XMLEncoder and java.beans.XMLDecoder.
Comment by project member eis...@gmail.com, Feb 2, 2010@jerdavis you're welcome to contribute
Comment by bryan.du...@gmail.com, Apr 4, 2010I do a lot of work on Thrift, and I've been very perplexed as to why Avro is so much faster than Thrift.
After some digging, I think I found one reason - Avro uses Utf8 as it's string type, which is fine, but I don't think the benchmark is taking into account the time it takes to actually decode these UTF8 objects before using them. Conversely, Thrift decodes its strings from UTF8 to String during deserialization.
In order for a complete test, I think you need to make Avro's benchmarks a "CheckingObjectSerializer?" and convert all the UTF8 fields to Strings. Otherwise, you're not benchmarking the time it actually takes to use the objects you've deserialized.
Comment by project member eis...@gmail.com, Apr 4, 2010Good point, you are welcome to post a bug report and submit a path. Thanks! Eishay
Comment by alexande...@gmail.com, Apr 8, 2010Any comments/additional performance test of jboss-remoting?
Comment by project member eis...@gmail.com, Apr 8, 2010@alexander Didn't try it out. you are welcome to contribute.
Comment by project member tsaloranta@gmail.com, Apr 9, 2010I agree wrt UTF-8 decoding; for usage that test seems to approximate, I don't think use of raw byte arrays would make sense.
Comment by david.ll...@redhat.com, Apr 27, 2010The equivalent JBoss project would be JBoss Marshalling, which tries to improve serialization performance while retaining some degree of spec compatibility. Check it out if you're interested in adding it to your comparative benchmark: http://www.jboss.org/jbossmarshalling/
Comment by project member eis...@gmail.com, Apr 27, 2010Thanks @david.lloyd, looks interesting, you are welcome to contribute
Comment by project member eis...@gmail.com, Apr 27, 2010The wiki moved to http://wiki.github.com/eishay/jvm-serializers/ For discussions please use http://groups.google.com/group/java-serialization-benchmarking
Comment by pikpik.1...@gmail.com, May 26, 2010Please show units (for example: seconds, nanoseconds) in all sections.
Comment by thomas.burdick@gmail.com, Jun 25, 2010Should add messagepack to this listing
Comment by project member eis...@gmail.com, Jun 25, 2010@thomas.burdick, you are welcome to contribute
Comment by isagol1...@gmail.com, Sep 12, 2010Hey Guys i am new about protobuf and i dont know well and i have a project. i have to provide a connection with embedded device and it must have small memory usage. maybe 900 byte(After compilation). Is it possible? i mean in this level of memory usage...
Comment by noop...@gmail.com, Oct 23, 2010@isagol1604: your main problem is that protobuf uses C++, not C, and C++ is not used on memory-constrained microcontrollers. But you can probably make a parser for simple protobuf-formatted messages in C.
Comment by twingl...@gmail.com, Dec 3, 2010Great work. Would love to see EXI added to the analysis.
Comment by project member eis...@gmail.com, Dec 3, 2010I'll be happy to see it as well! You're welcome to clone the project https://github.com/eishay/jvm-serializers and add EXI. If you're having problem please ask the forum: http://groups.google.com/group/java-serialization-benchmarking
Comment by openf...@gmail.com, Dec 11, 2010Any comments about Gson Parser ?
Comment by ggener...@gmail.com, Jun 6, 2011Isn't a JVM heap size of 16MB too small for this?
Comment by Vedmak-...@yandex.ru, Aug 24, 2011Hi Guys! Supports some of these Serialization Libraries deserialization of separate fields of object?
Comment by peter.la...@gmail.com, Oct 27, 2011Here is the result I get for the latest version. Perhaps its worth re-running these results.
, Object create, Serialize, /w Same Object, Deserialize, and Check Media, and Check All, Total Time, Serialized Size
avro-generic , 836.35500, 1744.00000, 1043.50000, 962.00000, 962.00000, 962.00000, 2706.00000, 211
avro-specific , 458.67000, 1174.50000, 764.00000, 1028.50000, 1028.50000, 1028.50000, 2203.00000, 211
activemq protobuf , 46.59000, 1199.00000, 183.50000, 5.50000, 605.00000, 920.00000, 2119.00000, 231
protobuf , 62.80000, 1162.50000, 770.50000, 568.50000, 785.00000, 804.00000, 1966.50000, 231
thrift , 63.46000, 1410.00000, 1540.50000, 1553.00000, 1553.00000, 1553.00000, 2963.00000, 353
hessian , 33.90000, 3374.50000, 3477.00000, 5676.00000, 5676.00000, 5676.00000, 9050.50000, 526
kryo , 34.75000, 936.00000, 1066.00000, 942.00000, 942.00000, 942.00000, 1878.00000, 226
kryo-optimized , 34.17500, 821.50000, 980.00000, 925.50000, 925.50000, 925.50000, 1747.00000, 207
MessagePack (buggy) , 34.08000, 880.50000, 983.00000, 671.50000, 671.50000, 671.50000, 1552.00000, 216
java , 34.38500, 4987.00000, 4727.50000, 23081.50000, 23081.50000, 23081.50000, 28068.50000, 919
java (externalizable) , 35.04500, 694.00000, 845.50000, 569.00000, 569.00000, 569.00000, 1263.00000, 264
WARN: serializer 'scala' failed round-trip test (ser+deser produces Object different from input), input=serializers.scala.MediaContent@2aa2cfbe, output=serializers.scala.MediaContent@23e3fe63
scala , 30.08000, 11186.00000, 10679.50000, 61878.50000, 61878.50000, 61878.50000, 73064.50000, 2024
json (jackson) , 34.60500, 1893.00000, 2166.00000, 1692.50000, 1692.50000, 1692.50000, 3585.50000, 378
json/jackson-databind , 35.66000, 8706.50000, 9068.00000, 9324.50000, 9324.50000, 9324.50000, 18031.00000, 1815
JsonMarshaller , 36.31500, 4705.50000, 5000.50000, 8225.50000, 8225.50000, 8225.50000, 12931.00000, 370
protostuff-json , 64.03500, 2088.00000, 2351.00000, 2098.50000, 2098.50000, 2098.50000, 4186.50000, 448
protostuff-numeric-json , 63.75000, 1890.00000, 2195.00000, 2022.50000, 2022.50000, 2022.50000, 3912.50000, 359
json/google-gson , 35.27000, 103919.00000, 104324.50000, 127536.50000, 127536.50000, 127536.50000, 231455.50000, 470
stax/woodstox , 34.94500, 2362.50000, 2788.00000, 3586.00000, 3586.00000, 3586.00000, 5948.50000, 475
stax/aalto , 35.16000, 1597.50000, 1756.50000, 2585.00000, 2585.00000, 2585.00000, 4182.50000, 475
binaryxml/FI , 36.81000, 5230.50000, 5468.50000, 4847.50000, 4847.50000, 4847.50000, 10078.00000, 300
xstream (stax with conv), 35.36000, 4420.50000, 4323.00000, 7983.50000, 7983.50000, 7983.50000, 12404.00000, 399
javolution xmlformat , 36.52000, 3673.50000, 3829.50000, 3664.00000, 3664.00000, 3664.00000, 7337.50000, 419
WARN: serializer 'sbinary' failed round-trip test (ser+deser produces Object different from input), input=serializers.scala.MediaContent@34305aac, output=serializers.scala.MediaContent@5290ecf8
sbinary , 30.76500, 1561.00000, 1745.00000, 998.50000, 998.50000, 998.50000