It all started when my colleague Joakim showed me the results of some JSON libraries benchmarks he was doing, which showed Jackson to be the clear winner among many libraries.

So I decided that for the upcoming CometD 2.4.0 release it would have been good to make CometD independent of the JSON library used, so that Jackson or other libraries could have been plugged in.
Historically, CometD made use of the Jetty‘s JSON library, and this is still the default if no other library is configured.

Running a CometD specific benchmark using Jetty’s JSON library and Jackson (see this test case) shows, on my laptop, this sample output:

Jackson is roughly 45% slower in parsing and 45% faster in generating, so not bad for Jetty’s JSON compared to the best in class.

Apart from efficiency, Jackson has certainly more features than Jetty’s JSON library with respect to serializing/deserializing custom classes, so having a pluggable JSON library in CometD is only better for end users, that can now choose the solution that fits them best.

Unfortunately, I could not integrate the Gson library, which does not seem to have the capability of deserializing arbitrary JSON into java.util.Map object graphs, like Jetty’s JSON and Jackson are able to do in one line of code.
If you have insights on how to make Gson work, I’ll be glad to hear.

The documentation on how to configure CometD’s JSON library can be found here.

After a suggestion from Tatu Saloranta of Jackson, the Jackson parsing is now faster than Jetty’s JSON library by roughly 20%:

CometD JSON library pluggability
Tagged on:                 

2 thoughts on “CometD JSON library pluggability

  • August 16, 2011 at 5:27 pm

    First of all, good to see even more performance testing. Progress in Java/JSON processing performance has been very exciting over time, and comparisons and competition tend to foster even more progress very nicely.

    One quick suggestion: make sure to do proper JVM warm up, i.e run tests couple of more times, discarding first runs. It takes multiple seconds for hotspot (et al) to do their job to get steady state of performance.

    Second thing to consider is that in general, use of String as JSON input is a rare use case, since content typically comes as a byte stream from external sources. So ideally input matches use case (InputStream, ByteBuffer), but even just using a byte[] gives better idea of optimal usage.

    Some more things I have noticed to be challenging when doing performance testing can be found from []

    Anyway, keep up the good job!

  • Pingback:CometD JSON library pluggability | Eclipse | Syngu

Comments are closed.