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:

Parsing:
...
jackson context iteration 1: 946 ms
jackson context iteration 2: 949 ms
jackson context iteration 3: 944 ms
jackson context iteration 4: 922 ms
jetty context iteration 1: 634 ms
jetty context iteration 2: 634 ms
jetty context iteration 3: 636 ms
jetty context iteration 4: 639 ms

Generating:
...
jackson context iteration 1: 548 ms
jackson context iteration 2: 549 ms
jackson context iteration 3: 552 ms
jackson context iteration 4: 561 ms
jetty context iteration 1: 788 ms
jetty context iteration 2: 796 ms
jetty context iteration 3: 798 ms
jetty context iteration 4: 805 ms

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.

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

...
jackson context iteration 1: 555 ms
jackson context iteration 2: 506 ms
jackson context iteration 3: 506 ms
jackson context iteration 4: 532 ms
jetty context iteration 1: 632 ms
jetty context iteration 2: 637 ms
jetty context iteration 3: 639 ms
jetty context iteration 4: 635 ms
CometD JSON library pluggability
Tagged on:                 

2 thoughts on “CometD JSON library pluggability

  • August 16, 2011 at 5:27 pm
    Permalink

    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 [http://www.cowtowncoder.com/blog/archives/2011/05/entry_455.html]

    Anyway, keep up the good job!

  • Pingback:CometD JSON library pluggability | Eclipse | Syngu

Comments are closed.