[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

RE: Updated Benchmark Available

---

---

And, in some cases, I think the relative performance may depend on the style
of XSL used. It's not just the mix of functions that matters, but the style
of applying them.  

Paul Tchistopolskii's "split then recurse" approach comes to mind since I'm
using the same technique to process a really long, flat sequence of elements
(output from an RTF to XML converter).  The project's stylesheet makes heavy
use of a tail recursive template.  

<nb>Tail recursion is when the result of a template is "something" followed
by the result of the template on a reduced version of the input.  For
example, tail recursion is probably a good way to handle a problem like
converting a flat set of elements into a more hierarchical set, like
converting a paragraph of text with emphasized words marked by "*".
[Lisp-ish version of algorithm at end -- I still think in Lisp, then
translate to XSL.]  Tail recursion is really just a form of iteration (or
vice-versa), but many languages implement it with a subroutine call instead
of a jump, and long tail recursions will overflow the call stack.</nb>

Since the depth of the call stack depends on the number of elements between
two "marker" elements, the XSL processor has to handle tail recursion
properly for my stylesheet to work without errors.

I've been using both Saxon and the MS Sept 2000 XSL.  It appears Saxon has
been faster with this sort of problem even with the overhead of loading
Java, and there's no sign (from memory usage) that I'd have trouble with a
really long sequence of elements.  I could be wrong -- the stylesheet has
continued to evolve after the switch to Saxon -- and I'll withhold final
comment until the application is finished.

When I'm a bit further along, I'll pass the stylesheet and input files along
to anyone who's interested.

Ken Meltsner

Lispish version of stylesheet logic:

(defun process-elements (elements)
   (cond
      ((null elements) nil)  ; empty list
      ((element-equal (first elements) "begin")
       (output (element "group"
                        (process-elements
                           (subsequence elements 1   
                                        ; 0-based numbering 
                                        (find "end" elements)))))
       (output (process-elements (subsequence elements
                                            (1+ (find "end" elements))
                                            (1- (length elements)))))
      (else
         (output (first elements))
         (process-elements (rest elements)))))

Minus any () errors, logic errors, etc., the template is (mostly)
tail-recursive when it's called.  (Although I cheated, a bit, by presumably
using a print or write to file or some other stateful operation when
(output) is called -- if I accumulated a long sequence of elements before I
returned, the template wouldn't be tail recursive.)



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

---