Subject: [xsl] More results in comparing the two makeHierarchy transformations From: "Dimitre Novatchev" <dnovatchev@xxxxxxxxx> Date: Wed, 3 Dec 2003 22:32:20 +0100 |
I was contacted off-list by both Markus Zelezny and David Tolpin. David provided me with his testing data. Markus asked me to publish the timing results and a summary. Here it is: I. Timing results. This time I was forced to use a faster (1.7GHz) but with less RAM (256MB) Pentium. David's data also proved "harder", which did not allow running the transformations with more than two different sets of data. The first series of tests uses an xml document containing 284 "node" elements. The second series of tests uses an xml document containing 568 "node" elements. The two transformations are marked as "SN" (from Simple and Native) and "CH" (from complex and Haskell). The tests involved running the two transformations on the two different inputs using the following 6 XSLT processors: MSXML4, Saxon 6.5.3, XalanJ 2.4.1, XalanC 1.5, .Net xsltTransform (nXslt.exe), JD 1.5.2 All results are in milliseconds: MSXML4 284 568 ==================================== SN 50.27 99.71 CH 1104 Stack Overflow Saxon 6.5.3 284 568 ==================================== SN 331 621 CH 3505 10165 JD 284 568 ==================================== SN 9163 36002 CH 3114 11607 XalanJ2.4.1 284 568 ==================================== SN 13759 50723 CH Stack Overflow Stack Overflow XalanC1.5 284 568 ==================================== SN 13149 52195 CH 8472 Crash (no err, partial output) .Net xsltTransform 284 568 ==================================== SN 15950 65198.98 CH Stack Overflow Stack Overflow What is obvious is the abnormal termination of CH in 6 of all 12 tests (5 times stack overflow and once a crash). SN was significantly faster than CH with MSXML4 and Saxon -- from 10 to 20 times faster. With these two XSLT processors SN showed linear time complexity. With the rest its complexity is quadratical. This most probably means that MSXML4 and Saxon are performing some clever optimizations, which the remaining processors don't do. CH was 3 times faster than SN with JD and was 1.5 times faster than SN with XalanC (but crashed with the larger input). Of all 6 processors only Saxon and JD seem to have some kind of tail-recursion optimization. This clearly means that in writing portable XSLT applications one should not rely on the presence of this feature. II. Conclusions? They should be obvious. I would welcome if other people opt to repeat these tests on their configurations. David, just in few words -- the problem with stack overflow can be overcome by using DVC-type recursion style (Divide and Conquer). Read about implementing DVC in XSLT here: http://www.topxml.com/code/default.asp?p=3&id=v20020107050418 or here: http://www.topxml.com/xsl/articles/recurse/ or search the list for DVC. ===== Cheers, Dimitre Novatchev. http://fxsl.sourceforge.net/ -- the home of FXSL XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[xsl] Tail recursion, David Tolpin | Thread | Re: In fact it's linear! (Was: Re: , Dimitre Novatchev |
[xsl] RE: XSL question (was: XSL qu, Josh Canfield | Date | [no subject], owner-xsl-list |
Month |