On Tue, Jun 30, 2009 at 7:06 AM, Guba, Nicolai<nguba_at_bioware.com> wrote:
> One thing that we have learned over the years is that it is impossible to predict performance empirically. One needs to measure the application and then compare measurements to determine whether any improvements actually yielded the expected results. You may be surprised what you find at times :) Like Paul mentioned earlier. Data is king!
Believe me, I have done plenty of performance measurements over my career. :)
(which is to say, I agree -- this just happens to be the case where I
have done quite a bit of measurements over various use cases)
> It must be said however, that we measured the effect of the request being processed by jaxb-json (which uses Jackson) versus 'plain' jersey where we used the java implementation of JSON and hand-crafted a protocol. To be fair, there may be plenty of reasons why this is slower, not just Jackson on it's own. I would arguge that it is a price worth paying though.
Ok. Yes, with JAXB route it does not greatly matter which parser is
used under the hood, because of requirements to build the full data
tree in memory, and various conversions.
At least when integration is by JSON parser implement Stax(XML) API. :-/
But more importantly, I was under impression that jaxb-json was using
Jettison, which uses json.org parser.
So I am not sure this has anything do with Jackson. Jackson is used
with some other variants tho (json natural?).
To get actual improvements you would use the Jackson jax-rs provider.
Even with full data binding it will be faster than anything you can
build on json.org's model (although it is perhaps 20-30% slower than
hand-crafted jackson streaming parser based alternative).
So if you can try it out I highly recommend checking this out. You can
still use JAXB for xml without problems.
> Unfortunately I cannot release any source code :( but such test should not be too difficult to set up on your own.
No sweat -- above explanation is enough to explain your results.
> Thank you for the background info in FI. Are there any recommendations for an efficient data format other than JSON or can we say that right now JSON would be our best option?
>
Just to clarify my statement: json when done without additional
mappings (like using Jackson data mapper without JAXB conversions etc)
is on par with FI. Json via Badgerfish (jettison -> json-jaxb) is
slower than FI.
If you can do that, yes, I would say json is the best best: unless you
want to minimize messsage size. FI can still compress data better if
minimal message size matters (with or without compression).
Even textual xml can compete with FI in many cases: Aalto xml parser
for example is roughly as fast for small-to-medium sized packages.
Here are some numbers:
http://code.google.com/p/thrift-protobuf-compare/
to give one data point regarding performance of various formats. JSON
does best out of textual formats.
(although I suspect that small message size may be bit unfair for FI,
and its number may be worse and for other use cases)
-+ Tatu +-