Subject: RE: XSL Optimizations From: "Wilson, James.W" <James.W.Wilson@xxxxxxxxxxxxx> Date: Mon, 21 Jun 1999 07:42:36 -0500 |
you don't need to re-parse the stylesheet with XT. I have successfully dropped it into a servlet which reads the stylesheet only on startup. I'm not sure if XT is reentrant out of the box, though. I can make the source available if people want it. Performance is quite good as a result (no numbers though, sorry). It might be even better to cache the rendering and only re-render as needed. James -----Original Message----- From: Lars Marius Garshol [mailto:larsga@xxxxxxxxxx] Sent: Monday, June 21, 1999 8:21 AM To: xsl-list@xxxxxxxxxxxxxxxx Subject: 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 XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: XSL Optimizations, Lars Marius Garshol | Thread | RE: XSL Optimizations, Earl Bingham |
Newbie question: how to count equal, Tarkanyi Ferenc | Date | Re: release of FOP, James Tauber |
Month |