More results in comparing the two makeHierarchy transformations

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