Subject: RE: Updated Benchmark Available From: "Meltsner, Kenneth" <Kenneth.Meltsner@xxxxxx> Date: Fri, 6 Oct 2000 10:36:25 -0400 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: Updated Benchmark Available, Kevin Jones | Thread | RE: Updated Benchmark Available, Kay Michael |
RE: A doubt in XML, Marcos Coelho | Date | Re: Updated Benchmark Available, Paul Tchistopolskii |
Month |