RE: XSL Optimizations

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.


-----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
| 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:

 XSL-List info and archive:

Current Thread