Re: [xsl] SAXON and exsl:node-set -- problem solved

[David Tolpin <dvd@xxxxxxxxxxxxxx>]

> Thanks for this insight. I'm sure there was no particular reason why the
> code was written the way it was - it's changed completely in Saxon 7.x.
> Interesting to see how dramatic the effect of a simple thing like this
> can be. The second argument to the Vector() constructor should have no
> effect on anything except performance.

Ok, I'll apply the patch to my version then. 

> I would be interested to know how you pinned it down.

I suspected that it happened due to an operation which was proportional to the
length of an array. There were two hypotheses:  
  - bad hash keys 
  - frequent copying of data (you mentioned copying of  trees).

To check the first hypothesis, I had replaced key lookups with xpath
expressions, expecting the performance to remain the same if the hypothesis
had been true; the stylesheet had run much longer. 

Then I looked for array declarations and found very few (which might be worth
checking), but discovered that java.util.Vector was used in many places. The
code for java/util/Vector checks whether the value for increment is zero, and
if it is, doubles the length, otherwise it just adds the increment to compute
the new length; there is also the only way to create Vector with non-zero
increment; that is, to call it with two arguments.

grep -E 'new Vector *([^)]+,[^)]+)' `find . -name '*.java'` 

(-E turns on 'normal' regular expressions)

has brought the right place.

> (As you probably realise, development on the Saxon 6.5 branch, apart from bug
> fixes, stopped over two years ago).

Yes, but XSLT 1.0 is still the most widely used variant of XSLT, and SAXON is
indeed the best XSLT processor of those available to me. I am having difficulty
learning the bigger XSLT 2.0 specification. Do you recommend already to use
SAXON 7 for XSLT 1.0 too? Is it mature enough for that?

David Tolpin

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