On Fri, Sep 19, 2008 at 5:24 PM, Ian Boston <[EMAIL PROTECTED]> wrote:
> Two things. > > Dom nearly always generates excessive object creation that under load > stresses the GC of any JVM, I did some comparisons for smallish XML blocks > between DOM and SAX (< 100 elements) a while back and there was perhapse 3x > on speed and 4x on memory, I cant remember the precise details. I understand > if its node manipulation thats required Dom is just easier and may be the > same weight, but if its xml -> object then it may be better to consider sax > or a push parser. Cocoon had some bad experience with dom in the request > cycle in v1 ( al long time ago when parsers were even more creaky) > Yeah, switching to sax would be a lot more efficient for the stuff that we do, but it would also require changing a lot more code (most likely we could write adapters for each object type to simplify it). > > > The other thing I have been told by IBMers is that their JVM makes it hard > to replace the Xerces impl. I dont know if thats relevant. > > The last 2 comments here http://jira.sakaiproject.org:8081/jira/ > browse/SAK-14388 > give some insight into a similar problem. > > > HTH > Ian > > On 19 Sep 2008, at 13:59, Kevin Brown wrote: > > I've noticed that the current performance of xml parsing is pretty bad. >> >> I've got a patch ready to go to improve this substantially. On our >> internal >> deployment it has cut down memory and CPU usage substantially and has >> significantly improved overall response time. >> >> Most of the changes that need to be made are compatible with fairly old >> xml >> parsers, but not so many work with pooling DocumentBuilders. For instance, >> xerces needs to be upgraded (I'm using 2.8.1, which is about 2 years old, >> and that works). >> >> Does anyone have any strong objections to upgrading xerces, or are there >> any >> instances of xml parsers being used that also don't support >> DocumentBuilder.reset ? >> > >
