cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Speed of jx-macros compared to FormsTransformer
Date Wed, 18 May 2005 08:12:00 GMT
Sylvain Wallez wrote:

> Leszek Gawron wrote:
>> Daniel Fagerstrom wrote:

>>                    -o0 Imports 0o-
>> Imports are used mainly for separating macro definitions from 
>> template itself. Issues:
>> 1. Template URI is resolved at runtime. We could skip this although 
>> this does not bring much overhead.
>> 2. Parsed template is looked up for every run. This way we are aware 
>> of the fact that imported parts are invalidated and should be 
>> reparsed. If we store the reference to the template instead of 
>> looking it up we've got xsl:import case: you would have to touch main 
>> template in order to have imported template changes reparsed.
> We have an important performance penality here because the import URI 
> isn't static and therefore can only be resolved a runtime and can 
> potentially point to a different template at each run.
> Two solutions to overcome this:
> - remove evaluation of the import uri and consider it as a pure static 
> string. I for one wasn't aware of this feature and find it more FS 
> than really useful. XSLT's href in xsl:include and xsl:import are 
> static and everybody lives happily with this.

Agree that we should get rid of dynamic template import. Dynamic XML 
import might still be non FS, though. So we should probably differ 
between template and XML import as Leszek propose.

> - distinguish at compile time between static uri that can be resolved 
> right away and therefore can be speedier, and uris needing evaluation 
> that have to pay the performance price of flexibility.
>> 3. Imported file is executed for every template run. That is why you 
>> have a lot of whitespace in the output where you import external file.
>> 4. Macro definitions are parsed at parse time but are REGISTERED in 
>> execution context during runtime 
>> (o.a.c.template.instruction.Define.execute inserts itself into the 
>> macro map in execution context). This is strictly connected with 2.: 
>> Changes in imported template have to be reflected somehow in 
>> execution context. Right now execution context is built from scratch 
>> every time.
>> 5. I think that evaluating lot's of jexl/jxpath expressions is 
>> awfully costly. I was debugging jxpath with FOM_Request problem and 
>> it gave me shivers. There's not much really we can do about it.
> What about using Rhino as the bean expression language in replacement 
> of JEXL? That way, expressions would be consistent with what's written 
> in flowscript.

It should be fairly easy to do, there is a pluggable Rhino 
implementation in JEX:

The plugable expressions in template are quite close to JEX, so it 
shouldn't be that difficult to adapt the JEX implementation for our needs.

But do you think it would affect performance? Furthermore, I agree that 
using the same EL everywhere would be good for consistence, OTH I would 
prefer having a read only EL in template instead of having an even more 


View raw message