RE: more on XSLT processor performance

> 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.

Yes. the actual factor depends very much on the XML complexity. The critical
thing is the size of element nodes. The Java VM uses (I believe) 24-30 bytes
per object before you even start putting any user data in. One approach
(like Xalan DTM) is to abandon implementing nodes as Java objects.
> 
> 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?

The first cut of that was done in Saxon 5.3 and made big improvements.
Getting more savings (without a radical rethink such as DTM) will involve
diminishing returns, and risk upsetting the space vs. time tradeoff.

I think xt's tree is done using chains whereas Saxon uses pointer arrays,
but I don't think that can be the sole reason for the difference in memory
usage, unless Java is allocating the arrays very inefficiently. I'm more
inclined to think that it's the dynamic memory usage that's different, not
the memory used for the tree itself.
> 
> 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.

Yes. There's masses of scope for good research projects in this area.

Mike Kay


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