On Thu, May 8, 2014 at 9:42 AM, Alan Conway <acon...@redhat.com> wrote:

> I vote for DispatchingDecode: it's the simplest, the fastest and is
> based on a well established parsing pattern with a good track record for
> performance (SAX). Its not so hard to ignore data in a handler.
> Writing a handler state machine is a bit more complex than writing a
> sequence of calls to a stream API, but I think you could encapsulate
> most of a standard state machine that given a sequence of type codes
> will fill a sequence of variables. Not sure about the right way to do
> that in Java performance-wise.
> Hmm. That might be worth another performance test though - if you did
> have such tools for making it easy to build handlers, would those tools
> introduce a penalty that would make the StreamingDecode look more
> attractive...

The biggest difference from an API perspective has to do with data
conversions/coersion. Say you're writing a piece of Java code that wants to
operate on Java integer or a Java float and doesn't care what the
underlying wire type is so long as it can be reasonable converted to that
type. In a stream style API you would simple write:

  int i = decoder.getInt();
  float f = decoder.getFloat();

The decoder implementation itself can the be smart enough to convert
whatever underlying wire type there might be into the appropriate java
type. The SAX API on the other hand will have a distinct callback for byte
vs ubyte vs short vs ushort, etc, and it could be quite cumbersome to
convert all the different possibilities into the type you actually want to
operate on. Put another way, the stream style API is capable of
incorporating the desired output type of the user, whereas the SAX style
API is not.

It might be possible to provide some kind of coercing handler that would
help the SAX situation. As you say though it's probably worth checking that
something like that would be usable and not introduce its own penalties.


Reply via email to