On Mar 12, 2007, at 18:43, Thomas Yip wrote:
Hi again,
Yes, I did log the time as follow:
long time1 = System.currentTimeMillis();
transformer.transform(src, res);
long time2 = System.currentTimeMillis();
And the difference between time2 and time1 is really about 40 seconds.
In command line, I redo the same test with the same XML and it takes
only 5 seconds.
I will try to increase the memory allocated to my apps server though
to see if there's a significant improvement and I'll let you know.
However, can the performance be affected if I have a XSL file that
includes many others XSL files when it is being used in a servlet, for
instance:
See my previous reply. I think the problem is not in the XSLT stage,
but actually happens before that.
Firstly, xmlWriter.toString() probably involves conversion/encoding
from bytes to characters. If the XML is large, then this also
consumes a significant amount of memory, as it will allocate a
backing char[] that is as long as the XML string. If you'd try this
with a 50MB XML-file in a servlet environment with a relatively small
amount of memory if calculated 'per user/process', then you're
already bound to run into trouble...
Then a StringReader is constructed around it. This is not very costly
(yet!).
Subsequently, you feed this StringReader into the constructor of a
StreamSource. If you look in the Javadocs of that particular
constructor, notice the remark that its use is actually discouraged.
Finally, the transform is initiated, and I fear that behind the
scenes, there is absolutely no buffering done in the StringReader, so
your XML-string gets read back in /one/ character at a time...
Conclusion: if you can, in any way, avoid the StringReader and
construct the StreamSource using an InputStream, preferably
BufferedInputStream, that should speed things up considerably IIC...
HTH!
Cheers,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
