> | I can blow up Xalan and Oracle fairly easily;
> 
> From private email I know what you mean by "blow up"
> here, but others might not. It does *not* mean "crash"
> but rather "make consume a lot of memory, thus causing
> my Java VM to page, thus sending it into a fit because
> Java VM's and paging to disk don't go well in the
> same sentence". 

> Recall that I sent you the results of your excellent 
> "Roman Graveyard" document and companion XSLT stylesheets 
> which, given enough memory, completes very quickly using
> our processor. Java VM's are funny when they start needing 
> to use virtual memory, so in your case with less memory you
> observed that the transformation looked like it took forever.
> Using your testcase and others we've worked for 2.0.2.9 on
> our memory usage so I'll hopefully have good news to report
> shortly on this front.

When I was experimenting with different XSLT engines, 
I found that only XT survived processing of  large documents, 
all other engines fail to scale  - the result usually was the 
"blow up" described above.

My experiment had nothing to do with 'complex' stylesheet.
Stylesheet itself was trivial. The source XML document  
was relatively big. ( If 1 Mb could be considered 'big' document )
The experiment was to generate different  XML files of the same structure
and feed the same stylesheet with  bigger and bigger and bigger 
XML file to see when engine will come to agony. Software development 
is sometimes exciting for sadists ( but mostly for masochists.).

Of course, I think that I should say   "only XT survived scaling 
on my box.  (128Mb of RAM)".

Given with the requirements Oracle 8 server places to RAM
( Question "how much memory will eat each network 
connection to Oracle 8 SQL server on Solaris" ? ), I think that 
in Oracle's universe the box with 128Mb of RAM is just not  
"given enough memory".

In universe of XT the same box is given enough memory.

That's one of reasons why I use XT. 

I understand that improving performance is such a routine 
operation that it will be earlier or later applied to all of 
XSLT engines. The thing is that  XT *already* has that 
operation applied (even not too much effort was spend 
in this direction. I mean XT could be even faster). 

Rgds.Paul.

PS.

Maybe SAXON is number two in the list. ( If XT would not 
exist - I'll be using SAXON - to me that is no question). 

Unfortunately, SAXON lacks some things which I'm using 
in XT and it is not as compact as XT ( because SAXON 
is solving many-many problems which are not interesting 
to me). 

PPS.

Even XT will finally be dropped by James Clark - I know 
some people who are ( still!!!! ) using perl4 ( not perl5 ). 
It takes a long  time for good thing to die.



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