Re: exsl:node-set in xalan

Michael,

I have tested it with Xalan (2.5.2). Memory usage is very similar
to that of SAXON, but it takes 40 sec (instead of more than 5 minutes
with SAXON) to process docbook.rng with exsl:node-set() , and 70
sec without (roughly same with SAXON), with several invocations of
the java machine. (I was wrong saying there are four invocations,
with 3 rinses there are 8), so, with 3 seconds per invocation on
my machine, the startup time is saved, and the result as it should
be.

Thus, it is not an issue with the data, but with implementation of
exsl:node-set().  What concerns me is that this behaviour is both
in SAXON (6.5.3) and jd.xslt 1.5.5.  It means  for me that there
may be something immanent to exsl:node-set that can reveal itself
in a similar way in other processors in circumstances.

As a matter of fact, I tried to check it with 4xslt too, but python
implementation is too slow for this experiment.


> > included? I expect it boils down to a memory issue: temporary trees,
> > with most implementations, are going to be held in memory, while final
> > result trees are not.
> 
> More testing results:
> 
> with 3 rinses (rinses=3 for XSLT glue, -3 for bash script), it takes 
> 
> - roughly the same time for xhtml, which about 80kb long). 
> - 7 (seven) times longer with exsl than with four invocations of the processor
>   with docbook stylesheets, which are about 900kb, that is roughly twice as big
>   as tei stylesheets used for the original processing (that was about 3 times longer)

David Tolpin
http://davidashen.net/

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