Re: SAX mode, DOM mode and caching

> > It is well known that XSL processors are usually faster in SAX
> > mode than in DOM mode : XT is a good example.
>
> You need to be clear about what you mean here. All current XSLT processors
> use a internal object model that may be a DOM or a proprietry model. If
you
> pass SAX events as input the processor still builds an object model. I
don't
> think there is any generic reason that creating an internal model from
> SAX events should be any quicker than from a DOM.

I don't know much about the internals of all the current XSLT processors but
XT can work in two different modes: SAX and DOM.
In both modes, the stylesheet is parsed into a proprietry DOM-like object
model (OM).
In the SAX input mode, an object model is still built but only for the
events used by the current processing, ignoring the non-relevant ones.

> > However to allow the caching of documents and stylesheets, I patched XT
to
> > add a hook in the DOM mode for a cache. So I now use it in a "cachable"
> DOM
> > mode which is faster than SAX.
>
> I am assuming you are caching the XT internal OM not a DOM per say. If so
> the speed improvement is simply because you are not building the XT
> internal object model each time.

I'm caching the XML documents as DOM trees, and the stylesheets as OM trees.

> > I've been thinking of a cacheable queue of SAX events. I would like to
> have
> > the opinion of you, folks, about this idea before trying to implement
it.
>
> XT is still going to have to convert those SAX events into a object model
> before it can use them. There is some saving in not re-parsing the
original
> XML but it won't match caching the XT object model.
>

I already cache the XT object model, I'm now looking for extra improvements
:
saving the re-parsing seems to be a good candidate.

Tangi



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list