[
Lists Home |
Date Index |
Thread Index
]
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 :-)
|
