This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
compiled stylesheets was Re: Re: RE: creating a string of repeated charactors
- To: <xsl-list at lists dot mulberrytech dot com>
- Subject: compiled stylesheets was Re: [xsl] Re: RE: creating a string of repeated charactors
- From: "cutlass" <cutlass at secure0 dot com>
- Date: Mon, 16 Jul 2001 10:45:23 +0100
- Cc: <xsl-list at lists dot mulberrytech dot com>
- References: <20010716090320.15875.qmail@web14502.mail.yahoo.com>
- Reply-To: xsl-list at lists dot mulberrytech dot com
----- Original Message -----
From: "Dimitre Novatchev" <dnovatchev@yahoo.com>
To: <timw@3d3.com>
Cc: <xsl-list@lists.mulberrytech.com>
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