Sanjiva Weerawarana wrote:
On Fri, 2006-03-31 at 18:07 +1200, Dennis Sosnoski wrote:
...
Adding support for Axiom to write directly to a stream/writer could help
a lot on this part.
I don't think we should do that .. in fact I've been meaning to respond
to your axiom restructuring proposal. IMO a key value of Axiom is its
tie into StAX and we shouldn't remove it. What we should do is write a
faster StAX writer if that's the culprit. I can't see why that's
inherently slower than having Axiom write to a stream and having similar
logic in Axiom.
Anytime you go through a layer of API it's going to be slower than doing
things directly. Hopefully the StAX writer API isn't adding more than
perhaps 10% overhead - but then why is Axiom output so slow? I don't
have an answer for this offhand.
As for the Axiom ties to StAX, I guess it really depends on whether you
see Axiom as a layer on top of StAX which allows incremental document
builds, or as a general build-on-demand model. I'd prefer the latter,
but if Axiom is just to be a layer on top of StAX I can make the data
binding code work within those constraints.
Have you done any perf tests for SOAP processing yet? IMO that's the
real benchmark we need to focus on ... Axiom's health and high
performance as a pure XML model is interesting and good, but its much
more important for us how it behaves in the patterns and scenarios of
SOAP.
I still need to update my complete set of comparisons. When I tried the
Axis-JiBX binding code it ran about half the speed of the JiBX-direct
code (using JibxSoap, still in pre-beta form). That was still about
twice as fast as XMLBeans, though, and XMLBeans was almost as fast as
Axis1 built-in binding the last time I checked.
- Dennis
