We cache the Templates object. We then took this a step further and started using translets. We noticed a marked performance improvement by caching the Templates and using translets.
http://xml.apache.org/xalan-j/xsltc_usage.html It was impossible for us to cache the source since it changed every transformation. Does your input remain the same over several invocations? If it does then you should cache the result of the transformation and use that when you don't have new input content. -Joe -----Original Message----- From: Karr, David [mailto:[EMAIL PROTECTED] Sent: Friday, September 09, 2005 3:57 PM To: [email protected] Subject: Performance of DOM/SAXSource vs. StreamSource & other optimization questions I haven't tried any of this yet, but I'm investigating options for optimizing XSLT. Caching the Transformer object is attractive, but synchronization issues will make this less attractive. I'm looking at implementing this in a messaging router, which could concievably be attempting the same conversion on 10 different threads at about the same time, and doing that many thousands of times in a day. I'm wondering instead about caching a Source object. Is it practical to do this? What about caching a DOMSource or SAXSource instead? I would guess that would be better than a plain StreamSource object. None of these classes say they are NOT thread-safe, so I assume they are ok with concurrent references (although I find that a little hard to believe). This would be implemented with JDK 1.4.2. Would the "Source" features be enabled in the stock JAXP implementation in that version? What does the "optimize" attribute in Xalan do? Is that available in the stock JAXP implementation?
