cocoon-dev mailing list archives

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

> Sylvain Wallez wrote:

>> 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.

Yes. We have to distinguish this in the instruction names. A <jx:macros 
href="blah"/> could be used for macro imports, whereas <jx:include> 
would be for dynamic XML import.

>> - 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?

Rhino has been reported to be fairly speedy, and also has a compilation 
mode that produces classes (i.e. bytecodes) on the fly.

> 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 powerfull.

I see your point. But a Rhino expression can only modify its context, 
which can be made read-only (see what I've done in flowscript to forbid 
automatic declaration of toplevel variables). Furthermore, this notion 
of "read-only" can't really be enforced when the expression language 
allows method calls.


Sylvain Wallez                        Anyware Technologies  
Apache Software Foundation Member     Research & Technology Director

View raw message