RE: [xsl] Memory housekeeping in Saxon and other XSLT processors ...

["Michael Kay" <michael.h.kay@xxxxxxxxxxxx>]

> Hi, what do you guys do if you have HUGE XML instances that 
> your transforms generate? Let's assume for a moment you have 
> a transform that replicates the input document 2 billion 
> times, or something similarly silly that really creates a 
> HUGE string of output tree. Is there anything in Saxon (or 
> other XSLT processors) that would try to keep a hold on the 
> whole tree even though it dumps tags to the output stream? 
> Are there any switches I need to set to make sure that memory 
> for result trees is freed after a result node has been output?

In Saxon:

Result trees are never actually built as trees in memory, unless you ask
for the output as a DOMResult. Instead, each node is serialized as it is
written.

Temporary trees are built in memory, and are discarded by the garbage
collector when there are no remaining references to them (typically,
when the variable goes out of scope). Memory requirements are also
reduced by delaying the building of the tree until it is actually
needed.

Source trees (including trees loaded using the document() function) are
held in memory for the duration of the transformation. 

> 
> I am having a problem with an XSLT based database dumper that 
> ends up haging after a while. I'm not sure if it is the JDBC 
> driver or server that hangs, but it's possible that Saxon 
> accumulates memory allocations. 

I've noticed a similar effect when using the Saxon SQL extensions, the
access to the database seems to progressively slow down, though in my
case it still continues to completion. I think it's a JDBC phenomenon.

Michael Kay
Software AG
home: Michael.H.Kay@xxxxxxxxxxxx
work: Michael.Kay@xxxxxxxxxxxxxx 


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