Even More About JSON performance in Java (now in technicolor!)
Thanks to suggestion by the friendly Japex author, I upgraded my testing set to the next level, consisting now of 2 Japex test suites: one that tests performance of small (up to 4 kB) documents, and another that tests performance of medium-sized documents (around 64 kB). Using Japex Micro-benchmark framework was a breeze, and its visualization capabilities make results much more sexy. So what's not to like? Anyway, initial results can be found from here:
In addition to Jackson (in streaming and java object tree modes), all previously mentioned alternate implementations are tested. But most interestingly I also found out about one more alternative, Noggit. Noggit (from Apache Labs) seems like a worthy competitor, given its good performance and small footprint. Its good quality is not a surprise given its author, who is a well-known fellow open sourceror (participating in projects like Lucene). I like its streamability, and design goals that include strict conformance to JSON specification.
Beyond implementations tested, I also added some artificial test documents (due to lack of real-world samples I could find), mostly to test larger document sizes, as well handling of numeric (integer, floating point) data. Numeric test cases are generated using simple generator classes, and other documents converted from xml documents (from xmltest test suite) using Badgerfish converter.
Results are interesting, although many of the findings are in line with my earlier tests. Beyond these similarities (regarding general ranking of implementations with respect to performance), there is the obvious correlation between streaming handling and performance for large documents: while tree models perform adequately for small documents, performance starts to seriously degrade with larger documents. This is analogous to XML processing performance (DOM vs. SAX/StAX). Also of interest was that one of the implementations apparently has problems parsing floating point numbers (which explains those NaN entries).
For anyone interested in reproducing the results, Japex source bundle (test cases, libs used) can be found here.
