1 Reply Latest reply on Oct 14, 2009 12:32 PM by Alexey Loubyansky

    Customizing XB and performance testing

    Alexey Loubyansky Master

      So, the previous tests show that generated parsers/handlers show the best time and significant difference. (Although the time and difference should be taken as a landmark value taking into account that Fast JAXB at this point is very limited in its features and doesn't even collect characters into string values correctly, although it's not affecting the current testcase). This could be a way to go.

      Starting from scratch though is not the best idea taking into account how much code is using XB and its custom features. Besides, XB-specific annotations and API features, XB kind of extends SAX events, i.e. to events like start/end element, characters, etc it adds start/end model group (sequence, choice, all, unordered sequence), start/end wildcard. This is necessary to support binding not only to types and elements but also to groups of elements. This is by the way is missing from JAXB as well at this point. And our projects do use this feature often.

      The good thing is that this SAX extension, i.e. the event-producing part of XB is separate from its event-handling part. So, the first thing to try going forward, IMO, would be to try to keep the event-producing part (which is based on SchemaBinding API) and try generating handlers for the event-handling part. In fact, in XB you can always write your own custom handler and plug it in. Which is what I did for the next test.

      Parser____first run__1_____10_____100_____1000

      first run - first parsing
      1, 10, 100, 1000 - number of iterations (parsings) after the first run
      the time is in milliseconds

      So, there is some improvement comparing to the default XB but we still don't beat JAXB and significantly slower than Fast JAXB.

      I am sure event-producing part can be optimized but it's difficult to say how much at this point.