Reinhard Poetz wrote:

Daniel Fagerstrom wrote:

Reinhard Poetz wrote:

<snip/>

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?

/Daniel



Reply via email to