You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2005/05/16 15:50:38 UTC
Speed of jx-macros compared to FormsTransformer
Sylvain Wallez wrote:
> Vadim Gritsenko wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Template:
>>> <ft:repeater-widget id="items">
>>> ...
>>> <input type="radio" name="selected-row"
>>> value="${repeaterLoop.index}"/>
>>> </ft:repeater-widget>
>>
>>
>>
>> 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 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 chance to speed up JX?
(If somebody wants to run the tests himself, he can find them in
trunk\tools\jmeter\CocoonForms_JXTemplate.jmx)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Speed of jx-macros compared to FormsTransformer
Posted by Reinhard Poetz <re...@apache.org>.
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 reason for this? Any chance to speed up JX?
>> (If somebody wants to run the tests himself, he can find them in
>> trunk\tools\jmeter\CocoonForms_JXTemplate.jmx)
>
>
>
> Are you using the new JXTG (in the templates block), or the old one?
JXTG in the template block
>
> The performance difference may be related to all the expression
> evaluations that occur in the template compared to the transforme.
this would be bad as those evaluations are runtime operations, aren't they?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Speed of jx-macros compared to FormsTransformer
Posted by Sylvain Wallez <sy...@apache.org>.
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 chance to speed up JX?
> (If somebody wants to run the tests himself, he can find them in
> trunk\tools\jmeter\CocoonForms_JXTemplate.jmx)
Are you using the new JXTG (in the templates block), or the old one?
The performance difference may be related to all the expression
evaluations that occur in the template compared to the transforme.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Speed of jx-macros compared to FormsTransformer
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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.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.
>
>
> IMHO, if attribute is present - regardless of whether it evaluates to
> null or not - body should be ignored. WDYT?
Exactly! Reinhard has updated trunk to this behaviour.
/Daniel
Re: Speed of jx-macros compared to FormsTransformer
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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 (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.
IMHO, if attribute is present - regardless of whether it evaluates to null or
not - body should be ignored. WDYT?
Vadim
Re: Speed of jx-macros compared to FormsTransformer
Posted by Leszek Gawron <lg...@mobilebox.pl>.
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 lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Speed of jx-macros compared to FormsTransformer
Posted by Reinhard Poetz <re...@apache.org>.
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 FormsTemplateTransformer :-) r170923 (2.1 branch, r170933 for
>> trunk) or later.
>
>
> ok, will have a look at it, hopefully at the weekend.
>
my recent tests show that your changes don't influence the performance, neither
positivly nor negativly. Or at least I can't measure it.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Speed of jx-macros compared to FormsTransformer
Posted by Reinhard Poetz <re...@apache.org>.
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, r170933 for
> trunk) or later.
ok, will have a look at it, hopefully at the weekend.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Speed of jx-macros compared to FormsTransformer
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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
later.
Vadim
http://svn.apache.org/viewcvs.cgi?rev=170923&view=rev
Re: Speed of jx-macros compared to FormsTransformer
Posted by Reinhard Poetz <re...@apache.org>.
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 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?
>>
>>
>>
>> here we go, same example again:
>>
>> complete jxt
>> cFormsTransformer 170 ms n/a
>> jx_macro_before 350 ms 250 ms
>> jx_macro_after* 190 ms 110 ms
>>
>> * implementing the change proposed by Daniel
>>
>> details can found here:
>> http://people.apache.org/~reinhard/jx_profiling/jx_macro_nostyle_after_change_template_packages.html
>>
>> http://people.apache.org/~reinhard/jx_profiling/jx_macro_nostyle_before_change_template_packages.html
>>
>
>
> You can't really derive any conclusions from single invocation. Collect
> profiling data over several minutes, results will be more reliable.
> Especially since time granularity is often ~ 10ms.
>
> And (don't know what your setup is ...) you can group together time
> taken by org.apache.xalan package - no need to collect CPU data on those...
ok
>
>> here the JMeter comparison using the test in
>> /trunk/tools/jmeter/CocoonForms_JXTemplate.jmx (10 parallel threads):
>>
>> form1 - JXTemplate
>> ******************
>>
>> url count average min max error rate
>> -------------------------------------------------------------------------
>> Load form 10 107 30 280 0,00% 11,2/sec
>> Enter Email-Adress (1) 500 114 20 541 0,00% 4,6/sec
>> Enter Email-Adress (2) 500 111 20 530 0,00% 4,6/sec
>> Start Over Request 500 122 20 541 0,00% 4,5/sec
>> TOTAL 1510 116 20 541 0,00% 13,6/sec
>>
>> form1 - FormsTransformer
>> ************************
>>
>> url count average min max error rate
>> -------------------------------------------------------------------------
>> Load form 10 55 50 80 0,00% 10,5/sec
>> Enter Email-Adress (1) 500 156 20 651 0,00% 4,5/sec
>> Enter Email-Adress (2) 500 147 20 641 0,00% 4,5/sec
>> Start Over Request 500 136 20 621 0,00% 4,6/sec
>> TOTAL 1510 145 20 651 0,00% 13,4/sec
>>
>> I can't explain why, but these two tests show that jx-macro is faster
>> than the transformer now, wow!
>
>
> 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)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Speed of jx-macros compared to FormsTransformer
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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 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?
>
>
> here we go, same example again:
>
> complete jxt
> cFormsTransformer 170 ms n/a
> jx_macro_before 350 ms 250 ms
> jx_macro_after* 190 ms 110 ms
>
> * implementing the change proposed by Daniel
>
> details can found here:
> http://people.apache.org/~reinhard/jx_profiling/jx_macro_nostyle_after_change_template_packages.html
>
> http://people.apache.org/~reinhard/jx_profiling/jx_macro_nostyle_before_change_template_packages.html
You can't really derive any conclusions from single invocation. Collect
profiling data over several minutes, results will be more reliable. Especially
since time granularity is often ~ 10ms.
And (don't know what your setup is ...) you can group together time taken by
org.apache.xalan package - no need to collect CPU data on those...
> here the JMeter comparison using the test in
> /trunk/tools/jmeter/CocoonForms_JXTemplate.jmx (10 parallel threads):
>
> form1 - JXTemplate
> ******************
>
> url count average min max error rate
> -------------------------------------------------------------------------
> Load form 10 107 30 280 0,00% 11,2/sec
> Enter Email-Adress (1) 500 114 20 541 0,00% 4,6/sec
> Enter Email-Adress (2) 500 111 20 530 0,00% 4,6/sec
> Start Over Request 500 122 20 541 0,00% 4,5/sec
> TOTAL 1510 116 20 541 0,00% 13,6/sec
>
> form1 - FormsTransformer
> ************************
>
> url count average min max error rate
> -------------------------------------------------------------------------
> Load form 10 55 50 80 0,00% 10,5/sec
> Enter Email-Adress (1) 500 156 20 651 0,00% 4,5/sec
> Enter Email-Adress (2) 500 147 20 641 0,00% 4,5/sec
> Start Over Request 500 136 20 621 0,00% 4,6/sec
> TOTAL 1510 145 20 651 0,00% 13,4/sec
>
> I can't explain why, but these two tests show that jx-macro is faster
> than the transformer now, wow!
Can you re-test with latest template transformer - just to confirm that it did
not got much slower after refactoring.
Thanks,
Vadim
Re: Speed of jx-macros compared to FormsTransformer
Posted by Sylvain Wallez <sy...@apache.org>.
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 Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Speed of jx-macros compared to FormsTransformer
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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 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?
>
>
> here we go, same example again:
>
> complete jxt
> cFormsTransformer 170 ms n/a
> jx_macro_before 350 ms 250 ms
> jx_macro_after* 190 ms 110 ms
>
> * implementing the change proposed by Daniel
>
> details can found here:
> http://people.apache.org/~reinhard/jx_profiling/jx_macro_nostyle_after_change_template_packages.html
>
> http://people.apache.org/~reinhard/jx_profiling/jx_macro_nostyle_before_change_template_packages.html
>
>
>
> here the JMeter comparison using the test in
> /trunk/tools/jmeter/CocoonForms_JXTemplate.jmx (10 parallel threads):
>
> form1 - JXTemplate
> ******************
>
> url count average min max error rate
> -------------------------------------------------------------------------
> Load form 10 107 30 280 0,00% 11,2/sec
> Enter Email-Adress (1) 500 114 20 541 0,00% 4,6/sec
> Enter Email-Adress (2) 500 111 20 530 0,00% 4,6/sec
> Start Over Request 500 122 20 541 0,00% 4,5/sec
> TOTAL 1510 116 20 541 0,00% 13,6/sec
>
> form1 - FormsTransformer
> ************************
>
> url count average min max error rate
> -------------------------------------------------------------------------
> Load form 10 55 50 80 0,00% 10,5/sec
> Enter Email-Adress (1) 500 156 20 651 0,00% 4,5/sec
> Enter Email-Adress (2) 500 147 20 641 0,00% 4,5/sec
> Start Over Request 500 136 20 621 0,00% 4,6/sec
> TOTAL 1510 145 20 651 0,00% 13,4/sec
>
> I can't explain why, but these two tests show that jx-macro is faster
> than the transformer now, wow!
That's more like it should be :)
It seem like there is some problem with the Invoker.toDOMNodeList when
it took 2/3 of the total time when applied on empty bodies.
Now it is harder to get any ideas what to optimize from the profiling
data, the profiler tool seem round of the figures to much. From the
figures right now it seem like nearly all of the work is done in code
outside jxtg which would be good but not seem entirely likely.
It still seem reasonable that the macro invocation is to costly, but we
need more exact profiling data to verify that.
Anyway, it is great that you have set up profiling and run tests, that
is exactly what is needed if we want to optimize our code.
/Daniel
Re: Speed of jx-macros compared to FormsTransformer
Posted by Reinhard Poetz <re...@apache.org>.
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. It
> is still strange that doing nothing should take so long time.
>
> Could you test the proposed change and post new profiling data?
here we go, same example again:
complete jxt
cFormsTransformer 170 ms n/a
jx_macro_before 350 ms 250 ms
jx_macro_after* 190 ms 110 ms
* implementing the change proposed by Daniel
details can found here:
http://people.apache.org/~reinhard/jx_profiling/jx_macro_nostyle_after_change_template_packages.html
http://people.apache.org/~reinhard/jx_profiling/jx_macro_nostyle_before_change_template_packages.html
here the JMeter comparison using the test in
/trunk/tools/jmeter/CocoonForms_JXTemplate.jmx (10 parallel threads):
form1 - JXTemplate
******************
url count average min max error rate
-------------------------------------------------------------------------
Load form 10 107 30 280 0,00% 11,2/sec
Enter Email-Adress (1) 500 114 20 541 0,00% 4,6/sec
Enter Email-Adress (2) 500 111 20 530 0,00% 4,6/sec
Start Over Request 500 122 20 541 0,00% 4,5/sec
TOTAL 1510 116 20 541 0,00% 13,6/sec
form1 - FormsTransformer
************************
url count average min max error rate
-------------------------------------------------------------------------
Load form 10 55 50 80 0,00% 10,5/sec
Enter Email-Adress (1) 500 156 20 651 0,00% 4,5/sec
Enter Email-Adress (2) 500 147 20 641 0,00% 4,5/sec
Start Over Request 500 136 20 621 0,00% 4,6/sec
TOTAL 1510 145 20 651 0,00% 13,4/sec
I can't explain why, but these two tests show that jx-macro is faster than the
transformer now, wow!
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Speed of jx-macros compared to FormsTransformer
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
Re: Speed of jx-macros compared to FormsTransformer
Posted by Sylvain Wallez <sy...@apache.org>.
Leszek Gawron wrote:
> Sylvain Wallez wrote:
>
>> Leszek Gawron wrote:
>>
>>>
>>> AAAAha!. That is a really important information.
>>> Invoker.toDOMNodeList is used by jx:set. This instruction is used
>>> mainly in jx-macros.xml like this:
>>>
>>> <jx:set var="cformsDummy" value="${cformsHelper.startForm(form,
>>> macro.arguments)}"/>
>>
>>
>> cformsDummy counts for 10 of the 25 <jx:set> in jx-macros.xml. So
>> having a <jx:call> would cut down a fair number of them.
>
> What do you mean by jx:call? jx:call executes a macro.
Ah yes. By "jx:call", I mean a way to evaluate an expression to call
some code without bothering of storing its result (which is void BTW) in
a variable.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Speed of jx-macros compared to FormsTransformer
Posted by Leszek Gawron <lg...@mobilebox.pl>.
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()
>>
>>
>> AAAAha!. That is a really important information. Invoker.toDOMNodeList
>> is used by jx:set. This instruction is used mainly in jx-macros.xml
>> like this:
>>
>> <jx:set var="cformsDummy" value="${cformsHelper.startForm(form,
>> macro.arguments)}"/>
>
>
>
> cformsDummy counts for 10 of the 25 <jx:set> in jx-macros.xml. So having
> a <jx:call> would cut down a fair number of them.
What do you mean by jx:call? jx:call executes a macro.
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Speed of jx-macros compared to FormsTransformer
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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()
>>
>>
>> AAAAha!. That is a really important information.
>> Invoker.toDOMNodeList is used by jx:set. This instruction is used
>> mainly in jx-macros.xml like this:
>>
>> <jx:set var="cformsDummy" value="${cformsHelper.startForm(form,
>> macro.arguments)}"/>
>
> cformsDummy counts for 10 of the 25 <jx:set> in jx-macros.xml. So
> having a <jx:call> would cut down a fair number of them.
As described in an earlier mail, there is (probably) a bug in the jx:set
implementation that make it call Invoker.toDOMNodeList when it shouldn't.
I'm against having a special instruction for performing side effects, as
side effects in templates is an anti pattern IMO. As long as we have
powerfull ELs we can't forbid it, but at least I think it is good that
it creates uggly looking code ;)
And as we allready have discussed, most of the uses of side effects in
jx-macros would go away with the use of XMLizable in widgets.
/Daniel
Re: Speed of jx-macros compared to FormsTransformer
Posted by Sylvain Wallez <sy...@apache.org>.
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()
>
> AAAAha!. That is a really important information. Invoker.toDOMNodeList
> is used by jx:set. This instruction is used mainly in jx-macros.xml
> like this:
>
> <jx:set var="cformsDummy" value="${cformsHelper.startForm(form,
> macro.arguments)}"/>
cformsDummy counts for 10 of the 25 <jx:set> in jx-macros.xml. So having
a <jx:call> would cut down a fair number of them.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Speed of jx-macros compared to FormsTransformer
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Reinhard Poetz 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.
>
>
> yes please, Leszek, any ideas?
>
>> 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)
>
>> 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)
>
>>
>> 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()
AAAAha!. That is a really important information. Invoker.toDOMNodeList
is used by jx:set. This instruction is used mainly in jx-macros.xml like
this:
<jx:set var="cformsDummy" value="${cformsHelper.startForm(form,
macro.arguments)}"/>
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Speed of jx-macros compared to FormsTransformer
Posted by Reinhard Poetz <re...@apache.org>.
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.
yes please, Leszek, any ideas?
> 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)
> 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)
>
> 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()
>> Any chance to speed up JX?
>
>
> Sure, give us profiling data ;)
here there are YourKit profiling data:
http://people.apache.org/~reinhard/jx_profiling/
- I always called http://localhost:8888/samples/blocks/forms/form1
once for the snapshots (controller is an action)
- I commented out the XSLT-Transformer and the i18nTransformer
- an initial request is the first call of an Cocoon Forms and a JXTemplate
pipeline
- a *non*-initial requests is done after some "warming-up" requests
and here there is an HTML export of the org.apache.cocoon.template method calls
in the example that uses jx-macro in a subsequent call:
http://people.apache.org/~reinhard/jx_profiling/jx_macro_nostyle_template_packages.html
Does this help?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Speed of jx-macros compared to FormsTransformer
Posted by Reinhard Poetz <re...@apache.org>.
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://people.apache.org/~reinhard/jx_profiling/ and
http://people.apache.org/~reinhard/jx_profiling/jx_macro_nostyle_template_packages.html.
(--> see http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111637652800527&w=2)
>
>> 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.
My first choice would be óptimizing JXTG. If this isn't successful because
external libraries are the problem, we can think of rewriting jx-macro.xml
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Speed of jx-macros compared to FormsTransformer
Posted by Leszek Gawron <lg...@mobilebox.pl>.
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 only and makes as much as possible at compile time. I'm *not*
> volountering ;)
me neither :))
<snip/>
> 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.
I'll look into that.
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Speed of jx-macros compared to FormsTransformer
Posted by Leszek Gawron <lg...@mobilebox.pl>.
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 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.
When dropping "runtime imports" constraints we have several
possibilities around.
> 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.
Runtime imports was an easy way to implement caching and macro
registration in execution context. I have never used
<jx:import uri="${dynamicUri}"/> and I think noone ever did. +1 to kill it.
I am thinking about having an import that does not produce content -
it's a little bit strange to have 2-3 pages of whitespace in your
generated source.
> 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 ...
>
> Vadim
>
> [1]
> http://cvs.apache.org/viewcvs.cgi/cocoon-2-historical/src/java/org/apache/cocoon/components/xslt/XSLTProcessorImpl.java?hideattic=0&rev=1.18.2.1&view=markup
>
> [2]
> http://svn.apache.org/viewcvs.cgi/excalibur/trunk/components/xmlutil/src/java/org/apache/excalibur/xml/xslt/XSLTProcessorImpl.java?rev=22712&view=markup
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Speed of jx-macros compared to FormsTransformer
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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 ...
Vadim
[1]
http://cvs.apache.org/viewcvs.cgi/cocoon-2-historical/src/java/org/apache/cocoon/components/xslt/XSLTProcessorImpl.java?hideattic=0&rev=1.18.2.1&view=markup
[2]
http://svn.apache.org/viewcvs.cgi/excalibur/trunk/components/xmlutil/src/java/org/apache/excalibur/xml/xslt/XSLTProcessorImpl.java?rev=22712&view=markup
Re: Speed of jx-macros compared to FormsTransformer
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
Re: Speed of jx-macros compared to FormsTransformer
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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:
>>> - remove evaluation of the import uri and consider it as a pure
>>> static string. I for one wasn't aware of this feature and find it
>>> more FS than really useful. XSLT's href in xsl:include and
>>> xsl:import are static and everybody lives happily with this.
>>
>>
>>
>> Agree that we should get rid of dynamic template import. Dynamic XML
>> import might still be non FS, though. So we should probably differ
>> between template and XML import as Leszek propose.
>
> Yes. We have to distinguish this in the instruction names. A
> <jx:macros href="blah"/> could be used for macro imports, whereas
> <jx:include> would be for dynamic XML import.
+1
I would prefer requiring that marco import declared the name space of
the imported macros in some way. I'm not to happy with that you must
check all imported macro declaration files to see if a tag is a macro or
not.
>> It should be fairly easy to do, there is a pluggable Rhino
>> implementation in JEX:
>> http://svn.apache.org/viewcvs.cgi/jakarta/commons/sandbox/jex/trunk/src/java/org/apache/commons/jex/javascript/.
>> The plugable expressions in template are quite close to JEX, so it
>> shouldn't be that difficult to adapt the JEX implementation for our
>> needs.
>>
>> But do you think it would affect performance?
>
> Rhino has been reported to be fairly speedy, and also has a
> compilation mode that produces classes (i.e. bytecodes) on the fly.
>
>> Furthermore, I agree that using the same EL everywhere would be good
>> for consistence, OTH I would prefer having a read only EL in template
>> instead of having an even more powerfull.
>
> I see your point. But a Rhino expression can only modify its context,
> which can be made read-only (see what I've done in flowscript to
> forbid automatic declaration of toplevel variables). Furthermore, this
> notion of "read-only" can't really be enforced when the expression
> language allows method calls.
>
I know :/
Anyway, a Rhino EL plugin seem like a valuable adition, I will start
implementing it as soon as we have finished the reals blocks ;) If
anybody want it sooner Sylvain and I have given some pointers about how
to get started.
/Daniel
Re: Speed of jx-macros compared to FormsTransformer
Posted by Sylvain Wallez <sy...@apache.org>.
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 the import uri and consider it as a pure
>> static string. I for one wasn't aware of this feature and find it
>> more FS than really useful. XSLT's href in xsl:include and xsl:import
>> are static and everybody lives happily with this.
>
>
> Agree that we should get rid of dynamic template import. Dynamic XML
> import might still be non FS, though. So we should probably differ
> between template and XML import as Leszek propose.
Yes. We have to distinguish this in the instruction names. A <jx:macros
href="blah"/> could be used for macro imports, whereas <jx:include>
would be for dynamic XML import.
>> - distinguish at compile time between static uri that can be resolved
>> right away and therefore can be speedier, and uris needing evaluation
>> that have to pay the performance price of flexibility.
>>
>>> 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.
>>
>>
>> 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.
>
>
> It should be fairly easy to do, there is a pluggable Rhino
> implementation in JEX:
> http://svn.apache.org/viewcvs.cgi/jakarta/commons/sandbox/jex/trunk/src/java/org/apache/commons/jex/javascript/.
> The plugable expressions in template are quite close to JEX, so it
> shouldn't be that difficult to adapt the JEX implementation for our
> needs.
>
> But do you think it would affect performance?
Rhino has been reported to be fairly speedy, and also has a compilation
mode that produces classes (i.e. bytecodes) on the fly.
> Furthermore, I agree that using the same EL everywhere would be good
> for consistence, OTH I would prefer having a read only EL in template
> instead of having an even more powerfull.
I see your point. But a Rhino expression can only modify its context,
which can be made read-only (see what I've done in flowscript to forbid
automatic declaration of toplevel variables). Furthermore, this notion
of "read-only" can't really be enforced when the expression language
allows method calls.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Speed of jx-macros compared to FormsTransformer
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Sylvain Wallez wrote:
> Leszek Gawron wrote:
>
>> Daniel Fagerstrom wrote:
>
<snip/>
>> -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.
>
> 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 the import uri and consider it as a pure static
> string. I for one wasn't aware of this feature and find it more FS
> than really useful. XSLT's href in xsl:include and xsl:import are
> static and everybody lives happily with this.
Agree that we should get rid of dynamic template import. Dynamic XML
import might still be non FS, though. So we should probably differ
between template and XML import as Leszek propose.
> - distinguish at compile time between static uri that can be resolved
> right away and therefore can be speedier, and uris needing evaluation
> that have to pay the performance price of flexibility.
>
>> 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.
>
> 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.
It should be fairly easy to do, there is a pluggable Rhino
implementation in JEX:
http://svn.apache.org/viewcvs.cgi/jakarta/commons/sandbox/jex/trunk/src/java/org/apache/commons/jex/javascript/.
The plugable expressions in template are quite close to JEX, so it
shouldn't be that difficult to adapt the JEX implementation for our needs.
But do you think it would affect performance? Furthermore, I agree that
using the same EL everywhere would be good for consistence, OTH I would
prefer having a read only EL in template instead of having an even more
powerfull.
/Daniel
Re: Speed of jx-macros compared to FormsTransformer
Posted by Sylvain Wallez <sy...@apache.org>.
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.mozilla.org/rhino/apidocs/org/mozilla/javascript/Context.html#compileString(java.lang.String,%20java.lang.String,%20int,%20java.lang.Object)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Speed of jx-macros compared to FormsTransformer
Posted by Leszek Gawron <lg...@mobilebox.pl>.
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 lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Speed of jx-macros compared to FormsTransformer
Posted by Sylvain Wallez <sy...@apache.org>.
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.
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 the import uri and consider it as a pure static
string. I for one wasn't aware of this feature and find it more FS than
really useful. XSLT's href in xsl:include and xsl:import are static and
everybody lives happily with this.
- distinguish at compile time between static uri that can be resolved
right away and therefore can be speedier, and uris needing evaluation
that have to pay the performance price of flexibility.
> 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.
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.
> 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.
>
>
>> 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.
>
>> 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 ;)
>
> 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.
>
> WDYT?
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Speed of jx-macros compared to FormsTransformer
Posted by Leszek Gawron <lg...@mobilebox.pl>.
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.
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.
> 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.
> 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 ;)
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.
WDYT?
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Speed of jx-macros compared to FormsTransformer
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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?
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.
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 ;)
/Daniel