cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Speed of jx-macros compared to FormsTransformer
Date Tue, 17 May 2005 21:30:23 GMT
Leszek Gawron wrote:
> Daniel Fagerstrom wrote:
>> Reinhard Poetz wrote:
>>> Sylvain Wallez wrote:
>> <snip/>
>>
>>>> Ah no, forgot to say: this requires to use JXTemplate and the 
>>>> forms-template-as-jx-macros.
>>>
>>> Today I've run some load tests that compare Cocoon Forms using 
>>> jx-macros and the FormsTransformer. The transformer is *considerably* 
>>> faster (~ factor of 3!) than the macros and the higher the load the 
>>> better for the transformer.
>>>
>>> Is there any special reason for this? 
>>
>> Macros has been reported to be slow before, IIRC. There is no reason 
>> that they should be, maybe they not are cached as they should be? 
>> Leszek has made the latest refactorings on the macros so he might have 
>> more info. The template and the macros should be much faster the 
>> second time they are execute, otherwise there is some problem with 
>> template caching. Do you have any numbers on  that?
> 
> Let me outline some resource heavy operations operations that are 
> performed in JXTG:
> 
>                    -o0 Parsing 0o-
> Although costly this shouldn't in fact affect runtime - parsed templates 
> are cached using transient store.
> 
>                    -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.
> 
> 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.

We could implement an own really minimal expression language that is 
read only and makes as much as possible at compile time. I'm *not* 
volountering ;)

> 6. Every element started in template is "suspected to be a macro call".
> 
> this means you can do:
> 
> <ft:widget id="something">
>    <inner-content/>
> </ft:widget>
> 
> instead of:
> <jx:call macro="widget">
>   <jx:withParam name="id" value="something">
>   <inner-content/>
> </jx:call>
> 
> 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.

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.
> 
> 2. runtime import works as it is working now. it is not allowed to 
> define macros there. I do not really know though if there should be such 
> distinction.
> 
> 3. parse time imports is only allowed to define macros and not produce 
> content. Template will not be run so no whitespace would be produced.
> 
> 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.
> 
> 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.

Anyway, during script compilation the URLs for the included scripts 
should be registred in the cache validity object, then the next time the 
script is executed, it can be checked if the main script or any imported 
scripts has been changed. And we don't need any runtime mechanism anymore.

>> But of course there can be bottle necks in different parts. We need 
>> profiling info to know where to start optimizing. Do you have any 
>> indication on where most of the time is spend?
>>
>>> Any chance to speed up JX?
>>
>> Sure, give us profiling data ;)

It is a serious proposal. It seem reasonable that the import mechanism 
and reflection in expression lanuages slow things down. But the only way 
to know for sure is to use profiling. There can be stuff that we think 
is fast that isn't.

> We could always rewrite jx-macros.xml to Java which will fix performace 
> problems for CForms (eliminating slow macro code and lots of 
> reflection). Still there is no consensus about that issue and we still 
> have a problem with other macros.

We should start by optimizing JXTG.

/Daniel

Mime
View raw message