xsl-list
[Top] [All Lists]

RE: Memory housekeeping in Saxon and other XSLT processors ...

2002-12-10 03:04:33
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(_dot_)H(_dot_)Kay(_at_)ntlworld(_dot_)com
work: Michael(_dot_)Kay(_at_)softwareag(_dot_)com 


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



<Prev in Thread] Current Thread [Next in Thread>