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