I'm certainly a little surprised by this result. The transformations are
fairly simple, so I guess that if it's taking 150 seconds then the data
files must be quite large, which is presumably why they are not
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)
jd.xslt shows very similar behavior.
I have tested it on two different computers (Linux and FreeBSD), with different
versions of JDK and different JIT compilers.
Memory requirements are quite modest, the heap size does not exceed 32M, and no
sensible swapping happens. I have some experience in debugging Java programs,
and I would not attribute it to memory shortage.
For completeness, I've posted an archive with test files to the server,
http://ftp.davidashen.net/incelim/tests.zip
David Tolpin
http://davidashen.net/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list