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 07:45:21 GMT
Reinhard Poetz wrote:

> Daniel Fagerstrom wrote:
>> Reinhard Poetz wrote:

>> 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?
> yes they are but macro execution takes still too long (IMHO)

It sure does, we are discussing possible solutions in another part of 
the thread.

>> Besides that does a lot of function calls through Jexl, that requires 
>> reflection an might be costly.
> hmmm, can't confirm this (but this is only my interpretation of the 
> profiling data and I'm *not* a profiling specialist)

I'm getting the same impression, which means that there are a lot of 
work to do in optimizing the rest, as reflection is supposed to be costly.

>> Generally a large part of the work is done at compile time, so it 
>> should at least in principle be efficient.
>> 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?
> AFAICS there is a lot of time spent in the macro execution methods and 
> especially in 
> org.apache.cocoon.template.jxtg.script.Invoker.toDOMNodeList()

That is interesting, toDOMNodeList(), seem to be called from the 
o.a.c.template.instruction.StartSet (has changed name to Set), which it 
only should be for jx:set with non empty body. And there are no such 
jx:set in jx-macros.xml.

The behaviour of jx:set should IMO be: if there is a value attribute, 
that should be evaluated and the value of the var attribute should be 
set to it, if there is not a value attribute the body should be 
evaluated and used instead. The current behaviour is instead: if there 
is a value attribute *and it doesn't evaluates to null* it is used, 
otherwise the body is used.

This behaviour was in the original JXTG as well. I don't know if it is 
by design or if it is a bug, anyway it is far to subtle for my taste. 
Having both a value attribute and a body should be considered as a 
syntax error.

If the null check for value at line 79 in Set is changed to a null test 
for this.value we get the behaviour that we should have IMO.

I would assume that the various jx:set for helper methods that has the 
return type void eavluates to null, and invokes the body evaluation. It 
is still strange that doing nothing should take so long time.

Could you test the proposed change and post new profiling data?


View raw message