Hi Ian: You're right, it's the gadget XML parse prior to manipulation. It's doing DOM-based parsing, and I suspect you're right about the load of small objects involved. At present I see that as a requirement, though, to deal with semi-well-formed input. We've talked about requiring XHTML or something close to it as a prerequisite for rewriting - which would make parsing vastly easier and rather trivial to implement - but that's a spec issue if it's to be a general platform requirement.
--John On Fri, Oct 3, 2008 at 12:53 AM, Ian Boston <[EMAIL PROTECTED]> wrote: > I don't know the precise details of this conversation or exactly which > parsing, CajaHtmlParser or XmlUtil.parse, you are talking about, but if its > the Gadget XML parse prior to manipulation, and this is still using DOM > based parsing, then its probably going to be slower than SAX under load, and > vastly slower than Stax. The reason I say under load, is that DOM parsers > tend emit lots of small objects which, once they get out of eden, overload > the GC which will dominate as resources become scarce. Having said that, > gadget parse trees probably don't exist long enough to get out of eden. > > Ignore me if you are talking about some other parsing going on within > gadgets. > Ian > > > On 3 Oct 2008, at 02:03, Kevin Brown wrote: > > The real thing we should be investigating is why it takes 25ms to use the >> parser on buddypoke when it only takes 10ms to cajole it. >> > >
