RE: XSL processor authors - how about this approach?
> >In this architecture, the operation which is taking most of > the cycles is the parsing of the XSLT sheet (which can take several > seconds) and is most of the time cached. Firstly, it is hardly ever true that parsing and preparing the stylesheet takes "most of the time". In most cases with Saxon it is around 20% of the time; the actual ratio is highly variable but the highest I have measured is 50%. It can seem longer than this because the Java VM is also warming up during this time, doing JIT compilation etc. > > Has anyone considered this kind of solution for server-side XSL? : > Take the stylesheet, parse it and generate a custom servlet > to perform this transformation. Then everytime XML needs to be transformed, > this servlet could be run. Saxon did at one time include an XSLT-to-Java compiler. I eventually abandoned it because it was getting too complex and the performance gains were too marginal. That doesn't mean the approach isn't viable, just that I didn't have the time and energy to complete it. Saxon does provide what is almost as good, a servlet environment in which the stylesheet is prepared once at start of day, and can then be used (interpretively) to process as many source documents as you like. Mike Kay XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format