Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Can you re-test with latest template transformer - just to confirm
that it did not got much slower after refactoring.
it's done with the refactored version (rev170868)
I meant FormsTemplateTra
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Can you re-test with latest template transformer - just to confirm
that it did not got much slower after refactoring.
it's done with the refactored version (rev170868)
I meant FormsTemplateTransformer :-) r170923 (2.1 branch, r1
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Can you re-test with latest template transformer - just to confirm
that it did not got much slower after refactoring.
it's done with the refactored version (rev170868)
I meant FormsTemplateTransformer :-) r170923 (2.1 branch, r170933 for trunk) or
lat
Vadim Gritsenko wrote:
Can you re-test with latest template transformer - just to confirm that
it did not got much slower after refactoring.
a performance competition ? :))
--
Leszek Gawron [EMAIL PROTECTED]
IT Manager Mo
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
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 eavlu
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
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 invok
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
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.templa
Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
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
Reinhard Poetz wrote:
I can't explain why, but these two tests show that jx-macro is faster
than the transformer now, wow!
Kewl :-)
Sylvain
--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
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 invok
Daniel Fagerstrom wrote:
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
Sylvain Wallez wrote:
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:
- r
Leszek Gawron wrote:
Sylvain Wallez wrote:
Leszek Gawron wrote:
ha!. That is a really important information.
Invoker.toDOMNodeList is used by jx:set. This instruction is used
mainly in jx-macros.xml like this:
cformsDummy counts for 10 of the 25 in jx-macros.xml. So
having a would cut d
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 th
Leszek Gawron wrote:
Sylvain Wallez wrote:
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.
Could you give us some pointers?
Have a look at o.a.c.forms.util.JavaScriptHelper and
http://www
Sylvain Wallez wrote:
Leszek Gawron wrote:
Reinhard Poetz wrote:
AFAICS there is a lot of time spent in the macro execution methods
and especially in
org.apache.cocoon.template.jxtg.script.Invoker.toDOMNodeList()
ha!. That is a really important information.
Invoker.toDOMNodeList is used by
Sylvain Wallez wrote:
Leszek Gawron wrote:
Reinhard Poetz wrote:
AFAICS there is a lot of time spent in the macro execution methods
and especially in
org.apache.cocoon.template.jxtg.script.Invoker.toDOMNodeList()
ha!. That is a really important information. Invoker.toDOMNodeList
is used b
Leszek Gawron wrote:
Reinhard Poetz wrote:
AFAICS there is a lot of time spent in the macro execution methods
and especially in
org.apache.cocoon.template.jxtg.script.Invoker.toDOMNodeList()
ha!. That is a really important information. Invoker.toDOMNodeList
is used by jx:set. This instructi
Sylvain Wallez wrote:
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
-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.
Sylvain Wallez wrote:
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.
Could you give us some pointers?
--
Leszek Gawron [EMAIL PROTECTED]
IT Manager
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
Sylvain Wallez wrote:
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 transforme
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
Sylvain Wallez wrote:
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 transform
Daniel Fagerstrom wrote:
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 o
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
Vadim Gritsenko wrote:
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 k
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
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.
checkout http:
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 lis
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
Sylvain Wallez wrote:
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
Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
Sylvain Wallez wrote:
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*
Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
Sylvain Wallez wrote:
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*
Sylvain Wallez wrote:
Reinhard Poetz wrote:
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 r
Reinhard Poetz wrote:
Sylvain Wallez wrote:
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!) tha
Reinhard Poetz wrote:
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? Any ch
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Template:
...
I don't think this will work in the template, does
FormTemplateTransformer supports this?
Ah no, forgot to say: this requires to use JXTemplate and the
forms-template-as-jx-macros.
Today I've run some lo
34 matches
Mail list logo
