Re: [xsl] Question of performance

["Thomas B. Passin" <tpassin@xxxxxxxxxxxx>]

For the processor to do what you say, it would have to understand both the
stylesheet and the xml document well enough to know that it wouldn't need to
move back and forth in the document.  This is a difficult problem, something
like optimizing a database query, and current processors can't do it.
That's why it would be better to break up your log file first, possibly
using SAX.

If you don't need to do this live on line, I would think about a batch
process that breaks up the log and saves the names of the fragments you want
to keep, then runs the xslt processor on those fragments (each of which
would have to be well-formed xml), finally combining the results.

Otherwise, you could use SAX to build a DOM that is only as big as you need
(it sounds like you won't be looking at all the entries), then handing that
DOM in-memory to the xslt processor, or pass the SAX events you are
interested in directly to an xslt processor's SAX interface.

Cheers,

Tom P

[Jay Kline]

The "preprocessing" is all that really needs to be done.  It is a log file
(in XML format) and I only want to display records that meet specific
conditions.  So initally there isnt any back and forth. Regardless, it is
somewhat unreasonable to load the entire file into memory. Does saxon, xslt,
or any other processor have the capibility of "streaming" where there would
be no back and forth (and not load the entire file into memory at once)?

[Tom Passin]

> The xslt processor might have to go back and forth within the xml
document,
> so any approach except having it all in memory would be very tricky.  Like
> sorting a very large file that can't be sorted all in memory, it could be
> done, but the xslt processors aren't at that point yet.
>
> Perhaps you can preprocess your xml file into smaller pieces, then combine
> the results afterwards.
>
> Cheers,
>
> Tom P
>



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