RE: more on XSLT processor performance

> > I agree. Saxon, at the current point in time, seems to be 
> the winner.
> > However, I'd like to see more compiled XSLT processors than 
> Java ones.
> > 5.5 hours to process a 69 MB file is not practical -
> 
> Compiling won't solve the memory problem. If we're going to make XSLT
> processing of such large files practical, the only way we'll 
> do it is by
> using persistent storage rather than memory for the tree.

My experience is that Saxon uses a factor of 10 in memory for representing the XML-file, which would mean that you would definitively use at least a machine with 512 Mb RAM for doing the above processing.

Since XT only uses half of that (reason unknown) would it be unreasonable to expect that the Saxon memory footprint could be reduced by careful analysis, and checking a lot for null references?

A pet peeve of mine would be that it might - in certain cases - be possible to apply XLST in streaming mode where only the necessary part of the tree is present in memory at any given point.  This would require quite some analysis of the XSLT program though.
-- 
  Thorbjørn Ravn Andersen   "...and...Tubular Bells!"


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