25 komentáře “Json Java parsers / generators microbenchmark

  1. Zpětný odkaz: JSON y Java: Introducción a Gson | danielme.com

  2. Zpětný odkaz: JSON Parser « Peace be with you

  3. Update 8/2012: Fastjson tests was added – it placed itself among the best performing libraries. Serialization is slightly worse than Jackson but in deserialization it is the clear winner.

    • If it supports POJO serialization and deserialization I would add it when have some spare time. According to docs it is supposed to work with POJOs.

      Or you can make benchmark test on your own and create a pull request. Thanks for suggestion.

      • fastjson support POJO, it’s api very simple:

        serialize API : JSON.toJSONString(obj);
        deserialize API : VO vo = JSON.parseObject(„…“, VO.class);

  4. I’m very interested in your work.

    I tried serialization benchmark last year.
    But the formats to serialize were XML and binary based.
    I would like to compare many approaches of object serialization from qualitative and quantitative aspects.

    Can I use your testing programs and the results in my benchmark?
    After finishing the experiments, I can open the results on my web site.

    Thank you.

    • Some more detail benchmarks are located at https://github.com/eishay/jvm-serializers/wiki/ (that I referenced in the article perex). But there are many approaches that could be tested – I took only one of them (POJO related).

      Of course you can use my source codes and use it for you own experimenting. Everything at this blog is Creative Commons licensed, so do with it what you will. Sources are at GitHub so you can fork easily if you like.

      Sharing your results will be highly appreciated.

      • I have read your source code in groovy. Thank you.

        In org/novoj/json/transformer/protostuff/ProtostuffIO.groovy, you wrote
        JsonIOUtil.writeTo(out, photoAlbum, schema, true)
        This statement serializes attribute names in numeric, for example,
        „2″:“John Doe“,
        „3″:“Speed kills!“,
        If you changed it to
        JsonIOUtil.writeTo(out, photoAlbum, schema, false)
        , the code serializes them in alphabetic,
        „name“:“John Doe“,
        „motto“:“Speed kills!“,
        This is a small thing, but I prefer the latter(false) to the former(true).

        And I would like to know about your information in English.
        I can not read your mother language :-<
        When I write technical documents, I would like to your name in acknowledgements.
        I wrote my contact information in my web page,
        Could you send email to me, please.
        Thank you very much.

  5. Source code? My measurements showed a closer race between Gson and Jackson.

    Don’t forget that gson’s jar is way smaller than Jackson’s: The gson-2.1.jar is 176 Kib; this includes both streaming and binding. To do both
    with Jackson you’ll need 874 Kib in .jar files.

    • Jackson for mobile device you can use minified jar which is ~134kb.
      Jackson mini doesn’t support annotations and which off-course is fine for mobile devices.

  6. Can you also put https://github.com/beckchr/staxon/ in equation to tell us how it performs. It seems like you have a set test that you running against all the api. It would really help to see how this new api performances in compare to Jackson. I am personally a fan of Jackson and their implementation but like the concept being staxon and the conversion capability in place between xml and json.

    Thanks for sharing

    • Staxon is focused on SAX like reading / writing and therefore I didn’t include it into the test suite in the first time. Test suite measures direct POJO serialization / deserialization and this is not main aim of the Staxon as I get it.

      After reading some docs I found out, that with combination with JaxB tags Staxson could be used for POJO serialization / deserialization so I’ll try to prepare a test for it. Check updates of this article please.

    • Staxon tests were finally added. I had some issues with switching serialization/deserialization factory in runtime. It seems library is optimized for choosing one factory at the start of the application and never change it (what is rather common usage I suppose).

  7. I had to rip all of jsonlib out last week as it seems to auto-parse strings beginning with „[“ or „{“ as json whenever you insert them into the object model, or attach a parent to another node.


    Try testing what the libs do with multiple entries of the same name; json-lib assumes you wanted an array of that name and aggregates them. similarly, see what rejects illegal JSON, such as unquoted keys: {illegal:true} or trailing commas. The authors think they are being helpful, but they are encouraging you to create invalid JSON.

  8. Yes, I focused on POJO serialization / deserialization which is quite common in web space (IMHO). Though according to this stats:


    Json-Smart places itself in the middle of the performance chart. Maybe in some specific use-case it jumps up?

    If you have your tests somewhere public it might be interesting to other readers to study your use-case it they give different results.

  9. I did extensive testing of json parsers with really large json data sets (parsing alone) and we never use POJO because it is simply a speed bump. In my tests, no other parser matched the speed of smart-json which is available in maven in it’s 1.0.9 version.

    Our use-case is slightly different though, we have to parse the json as fast as possible into managable hash maps to stay real-time.

    • Your findings are odd, because using POJOs should be faster than HashMaps, not slower. HashMaps have higher overhead than basic Java objects (due to key/value lookups), use up more memory, so their use does not make much sense to me for high-performance use cases.
      POJO binding is definitely faster than Maps with Jackson, at any rate. I have not found json-smart particularly fast — it appears to be medium speed (see [https://github.com/eishay/jvm-serializers/wiki]), which is good enough for many use cases.

  10. Yes, you’re right – in terms of performance Protostuff seems to be one of the best. But as I said in the beginning of the article:

    „I’ve used all libraries by same naive approach – grab it and use it the simpliest way possible. No tweaking, no optimalizing whatsoever (that’s the way they are usually used).“

    This library took me most time to integrate among all tested libraries, so I would recommend it for more serious work when you have time to study and try. For quick usage I wouldn’t go that way because Jackson or GSon are performant enough and much easier to use.