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. --Rafael
