Subject: Re: XSL Optimizations From: Lars Marius Garshol <larsga@xxxxxxxxxx> Date: 21 Jun 1999 14:21:18 +0200 |
* 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: XSL Optimizations, Jon Smirl | Thread | RE: XSL Optimizations, Wilson, James.W |
RE:, Harbarth, Juliane | Date | Re: side-effect-free (was Re: Can s, Lars Marius Garshol |
Month |