Return-Path: Delivered-To: apmail-xml-general-archive@xml.apache.org Received: (qmail 65184 invoked by uid 500); 28 Jun 2002 04:18:33 -0000 Mailing-List: contact general-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: general@xml.apache.org Delivered-To: mailing list general@xml.apache.org Received: (qmail 65172 invoked from network); 28 Jun 2002 04:18:33 -0000 Message-ID: From: "KUMAR,PANKAJ (HP-Cupertino,ex1)" To: "'xpb4j-users@lists.sourceforge.net'" Cc: "'xml-dev@lists.xml.org'" , "'general@xml.apache.org'" Subject: [XPB4J] RE: What's XSLT doing in here? Date: Fri, 28 Jun 2002 00:18:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: 209.66.108.5 1.6.2 0/1000/N Michael Kay Wrote: > As a comparison of XML parsing performance, this all seems reasonable. > But what is an XSLT processor, Xalan, doing in here? XSLT is an > application that processes the data that comes out of an XML parser. > If you want to measure XSLT performance, fine, but compare different > XSLT processors with each other, not with XML parsers! > Though an XSLT processor uses a parser internally and is perhaps meant for a different kind of processing with a different programming model, I have come across a number of situations where people decide whether to use XSLT or a program that uses DOM structure or SAX events. So, from that perspective I think it is reasonable to compare the performance of an XSLT based program with that of a parser based program, both doing the same thing. Especially in XML processing environments like Cocoon where programmers have the access to SAX event stream and also an XSLT Transformer, the choice isn't always very straight-forward. Now, I agree that the choice of processing I picked is not the ideal one for XSLT. > Actually I think it's rather remarkable how high a proportion of XSLT > processing time is accounted for by the XML parsing: often as much as > one-third. I am not familiar with internal workings of an XSLT transformer, so can't really comment on this. However, if any kind of XSLT processing requires building a DOM of the whole document then it will never be able to scale for very large documents. Pankaj Kumar URL: http://www.pankaj-k.net PS: I am posting the original message and my response to much wider audience than just xpb4j-users@lists.sourceforge.net. Just because there are so few XPB4J users right now and a bit of discussion would be healthy for XPB4J :-) --------------------------------------------------------------------- In case of troubles, e-mail: webmaster@xml.apache.org To unsubscribe, e-mail: general-unsubscribe@xml.apache.org For additional commands, e-mail: general-help@xml.apache.org