Since XSLT has full random access to the document., we do have to store it all in memory. We use our own DTM data model, which is significantly more space-efficient than a traditional Java DOM implementation... but data unavoidably takes up space. (Note: If you're passing in a DOM, ****STOP*** -- instead, pass in a SAX stream, and let us construct a DTM.)
Depending on what you're doing with the document, you may want to recode your transformation as custom code. A SAX-based application can be written so it stores only those pieces of data it intends to come back to, discards data as soon as it knows it will never be referenced again, and otherwise optimizes memory use. Yes, it is theoretically possible for an XSLT processor to apply many of those same optimizations. If you search the archives of this mailing list, and the Xalan developers' list, for the key words "streaming" and "pruning" you'lll find some past discussion of what would be involved in making that work. There has been some promising research done in this area... but we haven't yet had the resources needed to attempt incorporating that work into Xalan. ______________________________________ "... Three things see no end: A loop with exit code done wrong, A semaphore untested, And the change that comes along. ..." -- "Threes" Rev 1.1 - Duane Elms / Leslie Fish (http://www.ovff.org/pegasus/songs/threes-rev-11.html) "Burman Michael" <[EMAIL PROTECTED]> 02/26/2008 07:43 AM To <xalan-j-users@xml.apache.org> cc Subject Huge file transform problems.. Hi, Is there a solution how to reduce memory footprint of Xalan? In case I have a document, that's way too big to process in the memory (eating up to 6GB of memory with single-process) ? I'm using TRAX to transform the file these days, so would changing to StAX-transform solve this issue? My doubt is, that Xalan itself stores it in the memory. Or does someone have any better ideas? It's already a split file (from 7GB incoming XML-document..), and can't be splitted to smaller files anymore in our process. The processing file would be size of ~400MB, and this seems to eat huge amounts of memory when done with DOM+TRAX transform. - Micke
