Re: XSL Optimizations
* Lars Marius Garshol | | Another, and rather more ambitious idea is to turn patterns upside | down and have a map from element type names to patterns that may | match some descendant of that element type. Patterns can then be | added to and removed from this list on the way down the tree and | patterns invoked when their last requirement has been satisfied. * Jon Smirl | | Isn't this called a dataflow architecture? Not that I know of, but that means little. :) | My thoughts were something like this.. | | 1) I am currently unable to get very good performance out of | server-side XSL transforms. Using the MS implementation I'm at 150ms | and the LotusXSL Java implementation is 500ms for a page fetch from | the server. Immediate reactions: - why not use XT (it should be faster than LotusXSL) or SAXON's XSL-to-Java compiler to avoid having to constantly reparse the stylesheet? Also, there may be some payoffs from using the fastest possible SAX-compliant XML parser with those two. Another quick speedup may perhaps be gained from using a fast VM such as HotSpot. - are you sure you really need to redo the transformation for every page fetch? | 2) With server-side transformations it is ok to spend a lot time when the | stylesheet is initially loaded and cached. | 3) The DTD/schema would be loaded into the cached stylesheet. The DTD would | be analyzed to figure out the minimal set of patterns that need to be | checked at each node of the DTD/schema. | 4) The input document would be validated against the loaded schema and the | XSL patterns would be fired. | | Would this gain anything over the current implementations? Like I said: I doubt it, but feel free to try. Do run a profiler first, though. :) Like Didier says select is likely to be a costly operation, but my experience is that you should always run a profiler before starting to look for optimizations. Quite often one finds that some minor rewrite of a part of the program can give substantial improvements, so spending man-months on pattern interpretation may well give poor results on the man-day/ms scale. And since both SAXON and XT are open source you can just go ahead and start trying out ideas and doing research to find out where the bottlenecks are. | How expensive is it to use a validation algorithm as a way of | reducing patterns, I already know the documents are valid. You don't need to actually validate the documents to do what you described above. | Are there any XSL implementations in C or than Microsoft's? Perl and | PHP are shut out of the XSL world until there is a C implementation | available. There is one in pure Python. :) --Lars M. 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