[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
compiled stylesheets was Re: [xsl] Re: RE: creating a string of repeated charactors
Subject: compiled stylesheets was Re: [xsl] Re: RE: creating a string of repeated charactors From: "cutlass" <cutlass@xxxxxxxxxxx> Date: Mon, 16 Jul 2001 10:45:23 +0100 |
----- Original Message ----- From: "Dimitre Novatchev" <dnovatchev@xxxxxxxxx> To: <timw@xxxxxxx> Cc: <xsl-list@xxxxxxxxxxxxxxxxxxxxxx> Sent: Monday, July 16, 2001 10:03 AM> This template is "verbose" by necessity -- it solves the ***general*** case, when > neither the filling characters, nor an upper limit for the length are nown in > advance. > > It is also quite space-consuming (and time) -- because the string length is doubled > until a larger string is constructed, this will use twice as much memory, as > necessary for the resulting string. > i agree with Dimitre that there are much better ways of implementing most of the exslt templates with respect to memory use, though the javascript implementations are fairly optimized. as a rule of thumb the exslt templates are firstly created to illustrate clearly 'what is happening' ( i think ...), we hope that these functions will eventually be supported by the parsers or maybe we provide compiled versions of templates; that 'plug in' to parser structure. The days of optimizing from build start to end are nearly over ( gasp should i be saying this.....) in a world where things are still slow with 1 gig chip and 500 meg RAM, i am convinced that hardware advances ( and network ) will far outstrip code optimisation, and us programmers shall get lazier and lazier.. due to sheer ability to be lazy ( or not enough time to be super efficient ), not to mention that overall lifetime of any particular software is quite short lived ( at least the crap i write ). so using the lazy=efficient algorithim i would like to kick off debate on compiled stylesheets, as a possible 1st order standard optimisation here are some keypoints; - compiled stylesheets can occur as a translet, as defined by Sun's XSLTC effort, which compiles down the stylesheet into a java class, whereby the transformation happens with the assistance of a runtime library. - i would like to see a standard effort which is independant to java, are there any out there ? - is there any effort at the moment standardizing the integration of compiled stylesheets at runtime with major parsers? - would the use of TRAX be the first port of call in integrating compiled stylesheets, as TRAX seems to be adopted by major parsers ? due to this dependance on runtime library, i cannot see a standard method of adoption, unless of course the Sun runtime is incorporated into java xslt parsers, but this still doesnt solve language independance problem ( for those that do not want to work within java framework ). compiled stylesheets offer an interesting advantage in this situation, by gaining a significant performance gain, with clear verbose code, without the need ( this is the lazy part) to be overly concerned of optimisation. the demonstration of Sun's compiled stylesheets at XSLT UK was very interesting but there probably needs to be a meta data format that will allow for the standard integration of these stylesheets, maybe we will make another module for the exslt effort..... in a world where web services may deliver not just payloads of data, i can see payloads consisting of compiled stylesheets upgrading local applications ( and not necc being xslt ). any thoughts, jim fuller XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[xsl] Re: RE: creating a string of , Dimitre Novatchev | Thread | Re: compiled stylesheets was Re: [x, Robert Koberg |
Re: [xsl] Another (hopefully not st, Christian Cäsar | Date | Re: [xsl] Another (hopefully not st, Christian Cäsar |
Month |
Keywords