[xsl] More results in comparing the two makeHierarchy transformations

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


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)

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

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:


or here:


or search the list for DVC.


Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL

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

Current Thread