Subject: RE: XSLT vs Omnimark From: "Clementson, Bill" <Bill_Clementson@xxxxxxxxxxxxx> Date: Tue, 7 Mar 2000 12:38:22 -0700 |
>>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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: XSLT vs Omnimark, Juergen Hermann | Thread | Creating IMG tags using MSXML, Dan Reese |
Re: probably a stupid question, Carole E. Mah | Date | Re: using xt-extensions for getting, Jonathan Borden |
Month |