[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

RE: XSLT vs Omnimark

---

---

>>Didier replies:
>>Exactly. If you can implement an XSLT engine that is very fast, can handle
a
>>lot of transaction per second on the server side, which is compliant to
the
>>latest recommendations and which also allows the usage of JavaScript
>>(EcmaScript) function to produce a) text result, b) node list. You clearly
>>have a winner - and me as your first custommer.
>
> James Robertson replies:
>Yes, but how do you get around the fundamental
>requirement for a lot of RAM?
>
>I don't see how we can ever expect to parse a 150meg
>document using XSLT ...

The IBM/Apache Xalan XSLT processor uses something called a "Document Table
Model (DTM)" as a mechanism for improving performance. 

They say that it is: "a "pseudo-DOM" that uses integer arrays in place of
the DOM. For larger input and output trees, the performance improvements can
be very significant."

I haven't done any comparative performance testing - can anyone comment on
the effectiveness of this approach and whether any of the other XSLT
processors have taken a similar/different tack for improved performance &
reduced memory usage?

Bill


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

---