Subject: [xsl] Re: Efficiency Issues From: Dimitre Novatchev <dnovatchev@xxxxxxxxx> Date: Tue, 9 Apr 2002 09:42:33 -0700 (PDT) |
> My mind thinks of devilish plans to give away most of > the Business Logic or complex calculations to Java and receive it in > the XSL end and continue with display as usual. Would this kind of > Java object invocation lead to any performance issues?? As was recently discussed in this group, using extension functions within an XSLT transformation brings side effects and could at times result in unexpected/undesired anomalies. About efficiency: reasoning that using a compiled (in this concrete case Java) program is faster than an interpreted one (in this case an XSLT transformation) is correct but only if all other conditions are equal. A compiled implementation will not magically make faster a program that implements not the best algorithm and/or uses not the efficient data structures. Just a few days ago we had the example when an XSLT transformation using the FXSL function str-filter() significantly outperformed for string of moderate or greater length another one, which relied on the ***built-in*** function translate. Therefore, finding and applying the most efficient algorithm/data structures has higher precedence than the choice of compiled over interpreted programming language for the implementation. Just my 2c. Cheers, Dimitre Novatchev. __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] Dynamic javascript array , sicaudp | Thread | [xsl] gedML VS. the new gedcom xml , L Rutker |
[xsl] Dynamic javascript array load, sicaudp | Date | RE: [xsl] Floating point numbers in, Michael Kay |
Month |