On Fri, 2006-03-31 at 18:07 +1200, Dennis Sosnoski wrote: > I'm not much for profilers - they're okay for minor performance tuning, > but I see performance as a matter of design rather than tuning. > > Looking at these results, I suspect that as Eran suggested > XMLStreamWriter is not very performant compared to writing straight to > an output stream/writer. That might have a lot to do with why Axiom > output is so slow compared to dom4j and most of the document models - > those approachs all write directly to the output stream or writer. > 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. I'll respond to more of the restructuring stuff soon. 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. > On the input side, it looks like a lot of time is going into > constructing the tree within OMChildIterator. The parse time is a small > fraction of the total time here. Part of the Axiom overhead in building > the tree is probably due to the size of the data objects, which are more > than twice as large as dom4j. That aside, the code may just be > inefficient - I'll take a look and see if I spot anything obvious. OK cool. Sanjiva.
