cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: Speed of jx-macros compared to FormsTransformer
Date Wed, 18 May 2005 04:28:18 GMT
Daniel Fagerstrom wrote:
> Leszek Gawron wrote:
>> but you make the invoker look up element's name in macro map for EVERY 
>> template element started. Costly as hell. JX instructions are resolved 
>> the same way but during parsing. We cannot do the same for macros 
>> because we do not know the full macros list at parsing time.

What stops you from two-pass compiling? On first pass process all macros / 
instructions / etc, on second pass link'em up. This assumes that "runtime 
imports" are evicted.

> This sucks!
>>> Besides that does a lot of function calls through Jexl, that requires 
>>> reflection an might be costly.
>>> Generally a large part of the work is done at compile time, so it 
>>> should at least in principle be efficient.
>> If we are to speed up things we need to drop the fine feature of 
>> automatic change detection in imported templates. Then:
>> 1. Imports could be resolved at parse time/runtime depending on an 
>> attribute given. runtime imports generate content.

Is there a reason why imports should be resolved at runtime at all? Is there a 
need for two different import mechanisms? I'd suggest killing 'em.

>> 4. Execution context is built up on template parsing. It contains a 
>> full list of expected macros.
>> 5. <ft:widget id="something"> being a macro is being resolved at parse 
>> time, not runtime. A start element event is just a start element 
>> during runtime - never macro invocation.

With the above, it should be easy.

>> Now I know why XSLT guys made xsl:import the way it is.
> Sooner or later we should start write a CTemplateGenerator where we 
> remove stuff that we don't want from JXTG. It will share nearly all code 
> with JXTG the main difference is that it has a different instruction 
> configuration file. I don't know if it is time for it yet.
> Considering the automatic change detection, the situation isn't as bad 
> as you think.
> IIRC, Sylvain implemented a clever caching mechanism for the 
> TraxTransformer so that it detects changes in xsl:includes. I don't 
> rememember the details but maybe Sylvain can give some pointers.

IIRC, this feature was implemented in 2.0.3, almost 3 years ago. Look for usages 
of "protected List includes" [1]. It has been improved since then, with current 
version in excalibur [2].

[OT] I wonder why it uses Map now for m_includesMap ...



View raw message