As I said, I am new to Xalan,
I actually don't know I can avoid using
DOM with Xalan.  I saw the memory
usage is high, I assumed it is using DOM.

It may be using SAX, but, it still use a lot
of memory to be practical for our production
environment (we deal with large files).

Maybe something I did was not right, here is
how I used Xalan:

java -ms512m -mx512m -classpath
${XALAN_HOME}/bin/xalan.jar:${XALAN_HOME}/bin/x
ml-apis.jar:${XALAN_HOME}/bin/xerces.jar org.apache.xalan.xslt.Process -IN
$1 -X
SL /home/duan/supplier/ws_po.xsl -OUT $2

Here is how I use XSLTC:

java -classpath
${XALAN_HOME}/bin/xsltc.jar:${XALAN_HOME}/bin/runtime.jar:${XAL
AN_HOME}/bin/BCEL.jar org.apache.xalan.xsltc.compiler.XSLTC
/home/duan/supplier/
ws_po.xsl

java -ms512m -mx512m -classpath
${XALAN_HOME}/bin/xsltc.jar:${XALAN_HOME}/bin/ru
ntime.jar:${XALAN_HOME}/bin/BCEL.jar:/home/duan/supplier
org.apache.xalan.xsltc.
runtime.DefaultRun $1 ws_po

Any special command line flag I need to use to reduce
memory usage?

I think Xerces SAX parser is used here (default).

Thanks again!

Andrew Duan


> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 14, 2002 5:39 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: Why Xalan uses a lot of memory?
> 
> 
> 
> There isn't a single simple answer to that question.  If 
> there was, we'd
> already have dealt with it. Work is continuing on this.
> 
> First thing you should try is driving Xalan via SAX rather 
> than reading a
> DOM, if you haven't already done so; part of the tradeoff 
> that we accepted
> in DTM was improving the performance when building our own 
> model at the
> cost of losig some performance when we read from an existing DOM.
> 
> Note too that XSLTC is still an almost completely separate 
> implementation.
> We're currently working on integrating it with the main Xalan 
> codebase, but
> if you're reporting performance/size issues please be sure to report
> whether you used interpretive Xalan or compiled XSLTC, since 
> the issues are
> likely to be significantly different.
> 

Reply via email to