You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Leonardo Uribe <lu...@apache.org> on 2013/02/04 18:36:28 UTC

[core][discuss] Is it worth to include Stateless JSF / View Pooling concept into MyFaces?

Hi

Some time ago, this proposal was submitted to the consideration of this
list.

[core][proposal] JSF View Pooling (going beyond JSF Stateless Mode)

http://markmail.org/message/54rb3aphc6txwzbr

I have been thinking about the advantages and disadvantages of this
technique.

Advantages:

- Build view time is cut off, giving a speed improvement per each requests.
  Test done shows around 8% improvement in page rendering and in ajax case
  the improvement is even better, because in that case the build view time
  has more weight.
- A lot less objects are allocated.

Disadvantages:

- Detection technique to enable this optimization is not 100% fail-safe.
- It could create memory fragmentation, making garbage collection slower.
- Higher memory footprint.
- It is difficult to keep the code synchronized between versions of JSF,
because each concept related to view handling affects how the view pool
works.
- The use ui:param uses EL VariableResolver, makes the view non poolable,
  because the ValueExpression instances are not stateless in this case.

Do the advantages justify the introduction of this concept? Will users find
the improvement useful or applicable in real projects? or does not worth
the complexity involved and in this case keep thing simple is better?

regards,

Leonardo Uribe

-- 
[image: http://download.irian.at/2013/CONFESS_2013_email_signature.png]

Re: [core][discuss] Is it worth to include Stateless JSF / View Pooling concept into MyFaces?

Posted by Mark Struberg <st...@yahoo.de>.
-0.2 it is imo not really worth it. The benefits are just too small, and the complexity is too high.

LieGrue,
strub







>________________________________
> From: Thomas Andraschko <an...@gmail.com>
>To: MyFaces Development <de...@myfaces.apache.org> 
>Sent: Friday, February 8, 2013 6:31 PM
>Subject: Re: [core][discuss] Is it worth to include Stateless JSF / View Pooling concept into MyFaces?
> 
>
>+0 from my side.
>Hacking third party libraries is actually a no-go.
>
>
>2013/2/5 Leonardo Uribe <lu...@gmail.com>
>
>Hi
>>
>>2013/2/5 Thomas Andraschko <an...@gmail.com>:
>>
>>> Hi,
>>>
>>> from the performance perspective, it's a great feature. 8% and more are
>>> really much.
>>> On the other hand, i thought it would be more improvement (like 15-20%).
>>>
>>
>>That's the point. It is because the previous improvements done that the
>>difference now is only 8%.
>>
>>
>>> I don't know about the maintenance effort, maybe it would be better to
>>> search optimizations in other places.
>>>
>>
>>In this moment we have exhausted almost all the possibilities. We can
>>always improve the code, but in my opinion the gain if possible will be
>>very small (less than 1% or 2%).
>>
>>From maintenance perspective, the problem is that the hack requires some
>>changes in the component classes (specifically give the ability to reset
>>the state). So, it is necessary to change third party libraries to make it
>>work, and at the end the scope of the technique will be limited.
>>
>>Is maintenance a problem? in my opinion only if there is enough people
>>interested in use the code proposed.
>>
>>regards,
>>
>>Leonardo Uribe
>>
>>> Regards,
>>> Thomas
>>
>
>
>

Re: [core][discuss] Is it worth to include Stateless JSF / View Pooling concept into MyFaces?

Posted by Thomas Andraschko <an...@gmail.com>.
+0 from my side.
Hacking third party libraries is actually a no-go.

2013/2/5 Leonardo Uribe <lu...@gmail.com>

> Hi
>
> 2013/2/5 Thomas Andraschko <an...@gmail.com>:
> > Hi,
> >
> > from the performance perspective, it's a great feature. 8% and more are
> > really much.
> > On the other hand, i thought it would be more improvement (like 15-20%).
> >
>
> That's the point. It is because the previous improvements done that the
> difference now is only 8%.
>
> > I don't know about the maintenance effort, maybe it would be better to
> > search optimizations in other places.
> >
>
> In this moment we have exhausted almost all the possibilities. We can
> always improve the code, but in my opinion the gain if possible will be
> very small (less than 1% or 2%).
>
> From maintenance perspective, the problem is that the hack requires some
> changes in the component classes (specifically give the ability to reset
> the state). So, it is necessary to change third party libraries to make it
> work, and at the end the scope of the technique will be limited.
>
> Is maintenance a problem? in my opinion only if there is enough people
> interested in use the code proposed.
>
> regards,
>
> Leonardo Uribe
>
> > Regards,
> > Thomas
>

Re: [core][discuss] Is it worth to include Stateless JSF / View Pooling concept into MyFaces?

Posted by Leonardo Uribe <lu...@gmail.com>.
Hi

2013/2/5 Thomas Andraschko <an...@gmail.com>:
> Hi,
>
> from the performance perspective, it's a great feature. 8% and more are
> really much.
> On the other hand, i thought it would be more improvement (like 15-20%).
>

That's the point. It is because the previous improvements done that the
difference now is only 8%.

> I don't know about the maintenance effort, maybe it would be better to
> search optimizations in other places.
>

In this moment we have exhausted almost all the possibilities. We can
always improve the code, but in my opinion the gain if possible will be
very small (less than 1% or 2%).

>From maintenance perspective, the problem is that the hack requires some
changes in the component classes (specifically give the ability to reset
the state). So, it is necessary to change third party libraries to make it
work, and at the end the scope of the technique will be limited.

Is maintenance a problem? in my opinion only if there is enough people
interested in use the code proposed.

regards,

Leonardo Uribe

> Regards,
> Thomas

Re: [core][discuss] Is it worth to include Stateless JSF / View Pooling concept into MyFaces?

Posted by Thomas Andraschko <an...@gmail.com>.
Hi,

from the performance perspective, it's a great feature. 8% and more are
really much.
On the other hand, i thought it would be more improvement (like 15-20%).

I don't know about the maintenance effort, maybe it would be better to
search optimizations in other places.

Regards,
Thomas

Re: [core][discuss] Is it worth to include Stateless JSF / View Pooling concept into MyFaces?

Posted by Walter Mourão <wa...@gmail.com>.
Hi folks,
it looks to me it does not worth the effort of maintaining such a kind of
feature, since it has so many conditions to work and disadvantages.

Best regards,

Walter Mourão
http://waltermourao.com.br
http://arcadian.com.br
http://oriens.com.br


On Mon, Feb 4, 2013 at 3:36 PM, Leonardo Uribe <lu...@apache.org> wrote:

> Hi
>
> Some time ago, this proposal was submitted to the consideration of this
> list.
>
> [core][proposal] JSF View Pooling (going beyond JSF Stateless Mode)
>
> http://markmail.org/message/54rb3aphc6txwzbr
>
> I have been thinking about the advantages and disadvantages of this
> technique.
>
> Advantages:
>
> - Build view time is cut off, giving a speed improvement per each requests.
>   Test done shows around 8% improvement in page rendering and in ajax case
>   the improvement is even better, because in that case the build view time
>   has more weight.
> - A lot less objects are allocated.
>
> Disadvantages:
>
> - Detection technique to enable this optimization is not 100% fail-safe.
> - It could create memory fragmentation, making garbage collection slower.
> - Higher memory footprint.
> - It is difficult to keep the code synchronized between versions of JSF,
> because each concept related to view handling affects how the view pool
> works.
> - The use ui:param uses EL VariableResolver, makes the view non poolable,
>   because the ValueExpression instances are not stateless in this case.
>
> Do the advantages justify the introduction of this concept? Will users find
> the improvement useful or applicable in real projects? or does not worth
> the complexity involved and in this case keep thing simple is better?
>
> regards,
>
> Leonardo Uribe
>
> --
> [image: http://download.irian.at/2013/CONFESS_2013_email_signature.png]

Re: [core][discuss] Is it worth to include Stateless JSF / View Pooling concept into MyFaces?

Posted by Leonardo Uribe <lu...@gmail.com>.
2013/2/4 Grant Smith <gr...@marathonpm.com>

> Can it be optional, with a context param ?
>
>
Yes, it can be optional, that's the idea.

In this point we are in a situation where we need to be sure that the idea
is good enough to be included in MyFaces or not (not all possible ideas of
improvement can necessary qualify to be inside MyFaces Core).


>
> On Mon, Feb 4, 2013 at 9:36 AM, Leonardo Uribe <lu...@apache.org> wrote:
>
>> Hi
>>
>> Some time ago, this proposal was submitted to the consideration of this
>> list.
>>
>> [core][proposal] JSF View Pooling (going beyond JSF Stateless Mode)
>>
>> http://markmail.org/message/54rb3aphc6txwzbr
>>
>> I have been thinking about the advantages and disadvantages of this
>> technique.
>>
>> Advantages:
>>
>> - Build view time is cut off, giving a speed improvement per each
>> requests.
>>   Test done shows around 8% improvement in page rendering and in ajax case
>>   the improvement is even better, because in that case the build view time
>>   has more weight.
>> - A lot less objects are allocated.
>>
>> Disadvantages:
>>
>> - Detection technique to enable this optimization is not 100% fail-safe.
>> - It could create memory fragmentation, making garbage collection slower.
>> - Higher memory footprint.
>> - It is difficult to keep the code synchronized between versions of JSF,
>> because each concept related to view handling affects how the view pool
>> works.
>> - The use ui:param uses EL VariableResolver, makes the view non poolable,
>>   because the ValueExpression instances are not stateless in this case.
>>
>> Do the advantages justify the introduction of this concept? Will users
>> find
>> the improvement useful or applicable in real projects? or does not worth
>> the complexity involved and in this case keep thing simple is better?
>>
>> regards,
>>
>> Leonardo Uribe
>>
>> --
>> [image: http://download.irian.at/2013/CONFESS_2013_email_signature.png]
>
>
>
>
> --
> Grant Smith - V.P. Information Technology
> Marathon Computer Systems, LLC.
>

Re: [core][discuss] Is it worth to include Stateless JSF / View Pooling concept into MyFaces?

Posted by Grant Smith <gr...@marathonpm.com>.
Can it be optional, with a context param ?


On Mon, Feb 4, 2013 at 9:36 AM, Leonardo Uribe <lu...@apache.org> wrote:

> Hi
>
> Some time ago, this proposal was submitted to the consideration of this
> list.
>
> [core][proposal] JSF View Pooling (going beyond JSF Stateless Mode)
>
> http://markmail.org/message/54rb3aphc6txwzbr
>
> I have been thinking about the advantages and disadvantages of this
> technique.
>
> Advantages:
>
> - Build view time is cut off, giving a speed improvement per each requests.
>   Test done shows around 8% improvement in page rendering and in ajax case
>   the improvement is even better, because in that case the build view time
>   has more weight.
> - A lot less objects are allocated.
>
> Disadvantages:
>
> - Detection technique to enable this optimization is not 100% fail-safe.
> - It could create memory fragmentation, making garbage collection slower.
> - Higher memory footprint.
> - It is difficult to keep the code synchronized between versions of JSF,
> because each concept related to view handling affects how the view pool
> works.
> - The use ui:param uses EL VariableResolver, makes the view non poolable,
>   because the ValueExpression instances are not stateless in this case.
>
> Do the advantages justify the introduction of this concept? Will users find
> the improvement useful or applicable in real projects? or does not worth
> the complexity involved and in this case keep thing simple is better?
>
> regards,
>
> Leonardo Uribe
>
> --
> [image: http://download.irian.at/2013/CONFESS_2013_email_signature.png]




-- 
Grant Smith - V.P. Information Technology
Marathon Computer Systems, LLC.