You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@myfaces.apache.org by Marius Petoi <ma...@codebeat.ro> on 2010/06/18 09:19:17 UTC

[GSOC] State saving performance improvements in MyFaces 2.0

Hello,

In order to study the current performance of state saving, I designed a
small page that I included in the examples for MyFaces 2.0. Also, I wrote 2
phase listeners that determine the length of the state saved in the
ExternalContext before the render response phase and before the restore view
phase. Do you have any suggestions what components should I start analyzing
the state for?

Regards,
Marius

Re: [GSOC] State saving performance improvements in MyFaces 2.0

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

Hi Marius

It seems the optimization for ValueExpression / MethodExpression or
ValueBinding / MethodBinding
is not worth. The test data you provided shows a small improvement, but it
does not take into
account PartialStateHolder instances needs to be wrapped before save, so in
the end the
performance will be almost the same.

regards,

Leonardo Uribe

2010/7/21 Martin Marinschek <mm...@apache.org>

> Hi Marius,
>
> > --> Take for instance MethodExpressionActionListener. This is an example
> > where a MethodExpression is part of the state.
>
> then this should (and needs to be changed), right?
>
> >> Additionally, ValueExpression and MethodExpression are not implemented
> >> by us, so how can you implement StateHolder in this classes? Only in
> >> classes containing ValueExpressions, right?
> >
> > --> There are some implementations of MethodExpression and
> ValueExpression
> > in MyFaces, such as TagMethodExpression, which implement Externalizable.
> > These were the classes I was referring to earlier.
>
> ok, but even then, the underlying value-expression will not be touched
> by this changes. So your changes are only applying to a thin wrapper.
> So this should be negligible.
>
> best regards,
>
> Martin
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>

Re: [GSOC] State saving performance improvements in MyFaces 2.0

Posted by Martin Marinschek <mm...@apache.org>.

Hi Marius,

> --> Take for instance MethodExpressionActionListener. This is an example
> where a MethodExpression is part of the state.

then this should (and needs to be changed), right?

>> Additionally, ValueExpression and MethodExpression are not implemented
>> by us, so how can you implement StateHolder in this classes? Only in
>> classes containing ValueExpressions, right?
>
> --> There are some implementations of MethodExpression and ValueExpression
> in MyFaces, such as TagMethodExpression, which implement Externalizable.
> These were the classes I was referring to earlier.

ok, but even then, the underlying value-expression will not be touched
by this changes. So your changes are only applying to a thin wrapper.
So this should be negligible.

best regards,

Martin

-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: [GSOC] State saving performance improvements in MyFaces 2.0

Posted by Marius Petoi <ma...@codebeat.ro>.

Hi Martin,

On Wed, Jul 21, 2010 at 10:58 AM, Martin Marinschek
<mm...@apache.org>wrote:

> Hi guys,
>
> I didn´t follow this in absolute detail anymore right now, but:
>
> I do not think we should think about serializing MethodExpressions or
> ValueExpressions - IMHO, MethodExpressions or ValueExpressions should
> never be part of the partial state, cause a user will never change
> them programmatically (well, maybe in a very obscure corner case, but
> not generally).
>

--> Take for instance MethodExpressionActionListener. This is an example
where a MethodExpression is part of the state.

>
> Additionally, ValueExpression and MethodExpression are not implemented
> by us, so how can you implement StateHolder in this classes? Only in
> classes containing ValueExpressions, right?
>

--> There are some implementations of MethodExpression and ValueExpression
in MyFaces, such as TagMethodExpression, which implement Externalizable.
These were the classes I was referring to earlier.

>
> best regards,
>
> Martin
>

Re: [GSOC] State saving performance improvements in MyFaces 2.0

Posted by Martin Marinschek <mm...@apache.org>.

Hi guys,

I didn´t follow this in absolute detail anymore right now, but:

I do not think we should think about serializing MethodExpressions or
ValueExpressions - IMHO, MethodExpressions or ValueExpressions should
never be part of the partial state, cause a user will never change
them programmatically (well, maybe in a very obscure corner case, but
not generally).

Additionally, ValueExpression and MethodExpression are not implemented
by us, so how can you implement StateHolder in this classes? Only in
classes containing ValueExpressions, right?

best regards,

Martin

Re: [GSOC] State saving performance improvements in MyFaces 2.0

Posted by Marius Petoi <ma...@codebeat.ro>.

Hi Leonardo,

On Thu, Jul 15, 2010 at 8:38 AM, Leonardo Uribe <lu...@gmail.com> wrote:

> Hi Marius
>
> 2010/7/13 Marius Petoi <ma...@codebeat.ro>
>
> Hi Leonardo,
>>
>> I corrected the things you required in the JIRA issues. When you have the
>> time, please have a look over them. See inline my comments and questions:
>>
>> On Sun, Jul 11, 2010 at 3:57 AM, Leonardo Uribe <lu...@gmail.com> wrote:
>>
>>> Hi
>>>
>>> Sorry for the late response, but I was looking other important issues (I
>>> usually review issues with JSR-314 component first). I reviewed your patches
>>> and I committed some of them, and made comments on the others.
>>>
>>>  > On the other hand, regarding serialization vs implements
>>>>> PartialStateHolder,
>>>>> > I've looked for some more externalizable objects: the
>>>>> TagMethodExpression
>>>>> > class is used in the MethodExpressionValueChangeListener, which
>>>>> implements
>>>>> > StateHolder and PartialMethodExpressionValueChangeListener, which
>>>>> implements
>>>>> > PartialStateHolder.
>>>>>
>>>>> > So maybe instead of being Externalizable,
>>>>> > TagMethodExpression should also implement PartialStateHolder. There
>>>>> is a
>>>>> > similar situation with TagValueExpression.
>>>>>
>>>>> I guess - Leonardo should clarify.
>>>>>
>>>>>
>>> To save ValueExpressions, javax.faces.component._DeltaStateHelper uses an
>>> InternalMap, but that one does not take into account PartialStateHolder
>>> interface. So in this case does not apply.
>>>
>>> In MethodExpression it is possible, but to do that, we need to solve two
>>> questions:
>>>
>>> - If we have an immutable object that implements Serializable interface
>>> and a similar one that implements PartialStateHolder, which one is saved /
>>> restored faster? which one has bigger state size? It is worth to implement
>>> PartialStateHolder or keep it as Serializable?. To solve that we need to try
>>> some simple performance tests with possible candidates.
>>>
>>
>> --> Ok. How should I do that. This meaning do you have any suggestions for
>> objects or should I create some mock objects with identical data and then
>> compare the two strategies (in time and state size)?
>>
>
> Yes, it is a simple check but the important here is to know if the
> optimization is valuable or not.
>

--> I designed two simple classes: one implementing Serializable and the
other one implementing PartialStateHolder. The first class contains an
ArrayList of Strings. The other one a _DeltaList of Strings. I serialized
one object of each type to a byte array and measured the time necessary for
the serialization as well as the size of the resulting array. I varied the
number of elements in the list to 100, 1000, 10000. In both cases, the time
and size is proportional to the number of elements. So I will present only
the results for the 10000 elements list: in case serialization is used, the
size of the byte array is 50320 bytes, while for the _DeltaList it is 50055
bytes, so approximately the same. This is when the state consists of the
entire object, so no partial state was taken into consideration. The time
taken for the serialization of the list of 10000 Strings is 47 ms, while the
saveState method of the _DeltaList took 25 ms to execute. So the time taken
for the serialization is about 2 times bigger than in the case of the same
element designed using a PartialStateHolder (_DeltaList). I don't know how
general this example is...basically I compared the serialization of a  Java
object (ArrayList) with the state saving of an object implementing
PartialStateHolder (_DeltaList) and in this case serialization is not
better.

>
>
>>
>>> - Does all methods that store MethodExpression variables (
>>> UICommand.actionExpression) should handle PartialStateHolder interfaces? In
>>> theory yes (I add this support before but then I revert it to the current
>>> behavior because there is no evidence why use PartialStateHolder in this
>>> case), but if we don't expect MethodExpression implementations implements
>>> PartialStateHolder, just let it as is.
>>>
>>
>> --> By this you mean classes with MethodExpressions that use also
>> serialization and not implements PartialStateHolder. I've found a couple of
>> such classes: EventHandler.Listener and LegacyMethodBinding.
>>
>
> Yes. Note here to implement PartialStateHolder the target property that
> will use the MethodExpression should know how to deal with it. But this is
> worth only if the first idea is also true ( implement PartialStateHolder
> instead Serializable ).
>

--> Ok.So there are two classes that do not implement PartialStateHolder,
but have a MethodExpression field, so this is not ok.

>
>
>>
>>> Look this class:
>>> org.apache.myfaces.view.facelets.tag.jsf.core.SetPropertyActionListenerHandler
>>> . It has a inner class called SetPropertyListener that implements
>>> Serializable. javax.faces.component._DeltaList is used to store
>>> FacesListeners and that one handles PartialStateHolder instances. That one
>>> is other valid case.
>>>
>>
>> --> Ok. So should I transform this class into one implementing
>> PartialStateHolder?
>>
>
> In this case you should evaluate if it is worth this class implements
> PartialStateHolder.
>

--> It has two ValueExpression fields. ValueExpressions do not implement
PartialStateHolder. I redesigned the class to implement StateHolder and
written the saveState and restoreState methods. For these two classes, I
measured the time it took to serialize it to a byte array, as well as the
length of the resulting array. Here, like in the case of the list of
Strings, the execution of saveState is slightly faster than the
serialization (15 ms compared to 18 ms). The length of the resulting byte
array is 545 bytes in the case of serialization and 442 bytes in the case of
implements StateHolder. So making this class implement StateHolder would
bring a small improvement.

Regards,
Marius


> regards,
>
> Leonardo
>
>
>>
>>> best regards,
>>>
>>> Leonardo Uribe
>>>
>>
>> Regards,
>> Marius
>>
>>
>

Re: [GSOC] State saving performance improvements in MyFaces 2.0

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

Hi Marius

2010/7/13 Marius Petoi <ma...@codebeat.ro>

> Hi Leonardo,
>
> I corrected the things you required in the JIRA issues. When you have the
> time, please have a look over them. See inline my comments and questions:
>
> On Sun, Jul 11, 2010 at 3:57 AM, Leonardo Uribe <lu...@gmail.com> wrote:
>
>> Hi
>>
>> Sorry for the late response, but I was looking other important issues (I
>> usually review issues with JSR-314 component first). I reviewed your patches
>> and I committed some of them, and made comments on the others.
>>
>>  > On the other hand, regarding serialization vs implements
>>>> PartialStateHolder,
>>>> > I've looked for some more externalizable objects: the
>>>> TagMethodExpression
>>>> > class is used in the MethodExpressionValueChangeListener, which
>>>> implements
>>>> > StateHolder and PartialMethodExpressionValueChangeListener, which
>>>> implements
>>>> > PartialStateHolder.
>>>>
>>>> > So maybe instead of being Externalizable,
>>>> > TagMethodExpression should also implement PartialStateHolder. There is
>>>> a
>>>> > similar situation with TagValueExpression.
>>>>
>>>> I guess - Leonardo should clarify.
>>>>
>>>>
>> To save ValueExpressions, javax.faces.component._DeltaStateHelper uses an
>> InternalMap, but that one does not take into account PartialStateHolder
>> interface. So in this case does not apply.
>>
>> In MethodExpression it is possible, but to do that, we need to solve two
>> questions:
>>
>> - If we have an immutable object that implements Serializable interface
>> and a similar one that implements PartialStateHolder, which one is saved /
>> restored faster? which one has bigger state size? It is worth to implement
>> PartialStateHolder or keep it as Serializable?. To solve that we need to try
>> some simple performance tests with possible candidates.
>>
>
> --> Ok. How should I do that. This meaning do you have any suggestions for
> objects or should I create some mock objects with identical data and then
> compare the two strategies (in time and state size)?
>

Yes, it is a simple check but the important here is to know if the
optimization is valuable or not.


>
>> - Does all methods that store MethodExpression variables (
>> UICommand.actionExpression) should handle PartialStateHolder interfaces? In
>> theory yes (I add this support before but then I revert it to the current
>> behavior because there is no evidence why use PartialStateHolder in this
>> case), but if we don't expect MethodExpression implementations implements
>> PartialStateHolder, just let it as is.
>>
>
> --> By this you mean classes with MethodExpressions that use also
> serialization and not implements PartialStateHolder. I've found a couple of
> such classes: EventHandler.Listener and LegacyMethodBinding.
>

Yes. Note here to implement PartialStateHolder the target property that will
use the MethodExpression should know how to deal with it. But this is worth
only if the first idea is also true ( implement PartialStateHolder instead
Serializable ).


>
>> Look this class:
>> org.apache.myfaces.view.facelets.tag.jsf.core.SetPropertyActionListenerHandler
>> . It has a inner class called SetPropertyListener that implements
>> Serializable. javax.faces.component._DeltaList is used to store
>> FacesListeners and that one handles PartialStateHolder instances. That one
>> is other valid case.
>>
>
> --> Ok. So should I transform this class into one implementing
> PartialStateHolder?
>

In this case you should evaluate if it is worth this class implements
PartialStateHolder.

regards,

Leonardo


>
>> best regards,
>>
>> Leonardo Uribe
>>
>
> Regards,
> Marius
>
>

Re: [GSOC] State saving performance improvements in MyFaces 2.0

Posted by Marius Petoi <ma...@codebeat.ro>.

Hi Leonardo,

I corrected the things you required in the JIRA issues. When you have the
time, please have a look over them. See inline my comments and questions:

On Sun, Jul 11, 2010 at 3:57 AM, Leonardo Uribe <lu...@gmail.com> wrote:

> Hi
>
> Sorry for the late response, but I was looking other important issues (I
> usually review issues with JSR-314 component first). I reviewed your patches
> and I committed some of them, and made comments on the others.
>
>  > On the other hand, regarding serialization vs implements
>>> PartialStateHolder,
>>> > I've looked for some more externalizable objects: the
>>> TagMethodExpression
>>> > class is used in the MethodExpressionValueChangeListener, which
>>> implements
>>> > StateHolder and PartialMethodExpressionValueChangeListener, which
>>> implements
>>> > PartialStateHolder.
>>>
>>> > So maybe instead of being Externalizable,
>>> > TagMethodExpression should also implement PartialStateHolder. There is
>>> a
>>> > similar situation with TagValueExpression.
>>>
>>> I guess - Leonardo should clarify.
>>>
>>>
> To save ValueExpressions, javax.faces.component._DeltaStateHelper uses an
> InternalMap, but that one does not take into account PartialStateHolder
> interface. So in this case does not apply.
>
> In MethodExpression it is possible, but to do that, we need to solve two
> questions:
>
> - If we have an immutable object that implements Serializable interface and
> a similar one that implements PartialStateHolder, which one is saved /
> restored faster? which one has bigger state size? It is worth to implement
> PartialStateHolder or keep it as Serializable?. To solve that we need to try
> some simple performance tests with possible candidates.
>

--> Ok. How should I do that. This meaning do you have any suggestions for
objects or should I create some mock objects with identical data and then
compare the two strategies (in time and state size)?

>
> - Does all methods that store MethodExpression variables (
> UICommand.actionExpression) should handle PartialStateHolder interfaces? In
> theory yes (I add this support before but then I revert it to the current
> behavior because there is no evidence why use PartialStateHolder in this
> case), but if we don't expect MethodExpression implementations implements
> PartialStateHolder, just let it as is.
>

--> By this you mean classes with MethodExpressions that use also
serialization and not implements PartialStateHolder. I've found a couple of
such classes: EventHandler.Listener and LegacyMethodBinding.

>
> Look this class:
> org.apache.myfaces.view.facelets.tag.jsf.core.SetPropertyActionListenerHandler
> . It has a inner class called SetPropertyListener that implements
> Serializable. javax.faces.component._DeltaList is used to store
> FacesListeners and that one handles PartialStateHolder instances. That one
> is other valid case.
>

--> Ok. So should I transform this class into one implementing
PartialStateHolder?

>
> best regards,
>
> Leonardo Uribe
>

Regards,
Marius

Re: [GSOC] State saving performance improvements in MyFaces 2.0

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

Hi

Sorry for the late response, but I was looking other important issues (I
usually review issues with JSR-314 component first). I reviewed your patches
and I committed some of them, and made comments on the others.

> On the other hand, regarding serialization vs implements
>> PartialStateHolder,
>> > I've looked for some more externalizable objects: the
>> TagMethodExpression
>> > class is used in the MethodExpressionValueChangeListener, which
>> implements
>> > StateHolder and PartialMethodExpressionValueChangeListener, which
>> implements
>> > PartialStateHolder.
>>
>> > So maybe instead of being Externalizable,
>> > TagMethodExpression should also implement PartialStateHolder. There is a
>> > similar situation with TagValueExpression.
>>
>> I guess - Leonardo should clarify.
>>
>>
To save ValueExpressions, javax.faces.component._DeltaStateHelper uses an
InternalMap, but that one does not take into account PartialStateHolder
interface. So in this case does not apply.

In MethodExpression it is possible, but to do that, we need to solve two
questions:

- If we have an immutable object that implements Serializable interface and
a similar one that implements PartialStateHolder, which one is saved /
restored faster? which one has bigger state size? It is worth to implement
PartialStateHolder or keep it as Serializable?. To solve that we need to try
some simple performance tests with possible candidates.

- Does all methods that store MethodExpression variables (
UICommand.actionExpression) should handle PartialStateHolder interfaces? In
theory yes (I add this support before but then I revert it to the current
behavior because there is no evidence why use PartialStateHolder in this
case), but if we don't expect MethodExpression implementations implements
PartialStateHolder, just let it as is.

Look this class:
org.apache.myfaces.view.facelets.tag.jsf.core.SetPropertyActionListenerHandler
. It has a inner class called SetPropertyListener that implements
Serializable. javax.faces.component._DeltaList is used to store
FacesListeners and that one handles PartialStateHolder instances. That one
is other valid case.

best regards,

Leonardo Uribe

Re: [GSOC] State saving performance improvements in MyFaces 2.0

Posted by Marius Petoi <ma...@codebeat.ro>.

Hello,

I created a JIRA ticket with a patch that removes the
CompositeComponentResourceTagH
andler.ATTACHED_OBJECT_HADLERS_KEY from the component attributes map.
Instead it creates a map with the attached object handlers indexed by the
component reference. The JIRA ticket is:
https://issues.apache.org/jira/browse/MYFACES-2802

Please have a look over it and see whether it is ok.

Regards,
Marius


On Tue, Jul 6, 2010 at 5:38 PM, Martin Marinschek <mm...@apache.org>wrote:

> Hi Marius,
>
> > So, I am not sure what you mean by map with the Reference of the
> component
> > as the key...is it a map in which the keys are java.lang.ref.Reference
> > objects? And if so, what kind of references should I use?
>
> I meant you just put the component itself as a key there.
>
> > On the other hand, regarding serialization vs implements
> PartialStateHolder,
> > I've looked for some more externalizable objects: the TagMethodExpression
> > class is used in the MethodExpressionValueChangeListener, which
> implements
> > StateHolder and PartialMethodExpressionValueChangeListener, which
> implements
> > PartialStateHolder.
>
> > So maybe instead of being Externalizable,
> > TagMethodExpression should also implement PartialStateHolder. There is a
> > similar situation with TagValueExpression.
>
> I guess - Leonardo should clarify.
>
> best regards,
>
> Martin
>
> > On Tue, Jul 6, 2010 at 10:46 AM, Martin Marinschek <
> mmarinschek@apache.org>
> > wrote:
> >>
> >> Hi Marius,
> >>
> >>
> >> >>  problem here is since this call occur in build time, we can't call
> >> >> getClientId() (it will cause problems because the parent for most
> >> >> components
> >> >> is null in this stage), so use a external map here
> >> >> Why not use the Reference of the component as the key? Over one
> >> >> request,
> >> >> the reference is stable enough!
> >> >
> >> > Yes, it is possible. Just we have to take care about
> >> > ClientBehaviorRedirectEventComponentWrapper, because this class is
> used
> >> > as a
> >> > wrapper to redirect client behavior events.
> >> >
> >> > Note that
> >> > CompositeComponentResourceTagHandler.ATTACHED_OBJECT_HADLERS_KEY
> >> > list is not saved on the state, but since we use the component
> attribute
> >> > map, the key and the null value is saved on the state. If we don't use
> >> > the
> >> > component attribute map, we don't have that trace on the state and it
> >> > will
> >> > be lower.
> >>
> >> any update on this?
> >>
> >> best regards,
> >>
> >> Martin
> >
> >
>
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>

Re: [GSOC] State saving performance improvements in MyFaces 2.0

Posted by Martin Marinschek <mm...@apache.org>.

Hi Marius,

> So, I am not sure what you mean by map with the Reference of the component
> as the key...is it a map in which the keys are java.lang.ref.Reference
> objects? And if so, what kind of references should I use?

I meant you just put the component itself as a key there.

> On the other hand, regarding serialization vs implements PartialStateHolder,
> I've looked for some more externalizable objects: the TagMethodExpression
> class is used in the MethodExpressionValueChangeListener, which implements
> StateHolder and PartialMethodExpressionValueChangeListener, which implements
> PartialStateHolder.

> So maybe instead of being Externalizable,
> TagMethodExpression should also implement PartialStateHolder. There is a
> similar situation with TagValueExpression.

I guess - Leonardo should clarify.

best regards,

Martin

> On Tue, Jul 6, 2010 at 10:46 AM, Martin Marinschek <mm...@apache.org>
> wrote:
>>
>> Hi Marius,
>>
>>
>> >>  problem here is since this call occur in build time, we can't call
>> >> getClientId() (it will cause problems because the parent for most
>> >> components
>> >> is null in this stage), so use a external map here
>> >> Why not use the Reference of the component as the key? Over one
>> >> request,
>> >> the reference is stable enough!
>> >
>> > Yes, it is possible. Just we have to take care about
>> > ClientBehaviorRedirectEventComponentWrapper, because this class is used
>> > as a
>> > wrapper to redirect client behavior events.
>> >
>> > Note that
>> > CompositeComponentResourceTagHandler.ATTACHED_OBJECT_HADLERS_KEY
>> > list is not saved on the state, but since we use the component attribute
>> > map, the key and the null value is saved on the state. If we don't use
>> > the
>> > component attribute map, we don't have that trace on the state and it
>> > will
>> > be lower.
>>
>> any update on this?
>>
>> best regards,
>>
>> Martin
>
>



-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: [GSOC] State saving performance improvements in MyFaces 2.0

Posted by Marius Petoi <ma...@codebeat.ro>.

Hello,

So, I am not sure what you mean by map with the Reference of the component
as the key...is it a map in which the keys are java.lang.ref.Reference
objects? And if so, what kind of references should I use?

On the other hand, regarding serialization vs implements PartialStateHolder,
I've looked for some more externalizable objects: the TagMethodExpression
class is used in the MethodExpressionValueChangeListener, which implements
StateHolder and PartialMethodExpressionValueChangeListener, which implements
PartialStateHolder. So maybe instead of being Externalizable,
TagMethodExpression should also implement PartialStateHolder. There is a
similar situation with TagValueExpression.

Regards,
Marius

On Tue, Jul 6, 2010 at 10:46 AM, Martin Marinschek
<mm...@apache.org>wrote:

> Hi Marius,
>
>
> >>  problem here is since this call occur in build time, we can't call
> >> getClientId() (it will cause problems because the parent for most
> components
> >> is null in this stage), so use a external map here
> >> Why not use the Reference of the component as the key? Over one request,
> >> the reference is stable enough!
> >
> > Yes, it is possible. Just we have to take care about
> > ClientBehaviorRedirectEventComponentWrapper, because this class is used
> as a
> > wrapper to redirect client behavior events.
> >
> > Note that
> CompositeComponentResourceTagHandler.ATTACHED_OBJECT_HADLERS_KEY
> > list is not saved on the state, but since we use the component attribute
> > map, the key and the null value is saved on the state. If we don't use
> the
> > component attribute map, we don't have that trace on the state and it
> will
> > be lower.
>
> any update on this?
>
> best regards,
>
> Martin
>

Re: [GSOC] State saving performance improvements in MyFaces 2.0

Posted by Martin Marinschek <mm...@apache.org>.

Hi Marius,


>>  problem here is since this call occur in build time, we can't call
>> getClientId() (it will cause problems because the parent for most components
>> is null in this stage), so use a external map here
>> Why not use the Reference of the component as the key? Over one request,
>> the reference is stable enough!
>
> Yes, it is possible. Just we have to take care about
> ClientBehaviorRedirectEventComponentWrapper, because this class is used as a
> wrapper to redirect client behavior events.
>
> Note that CompositeComponentResourceTagHandler.ATTACHED_OBJECT_HADLERS_KEY
> list is not saved on the state, but since we use the component attribute
> map, the key and the null value is saved on the state. If we don't use the
> component attribute map, we don't have that trace on the state and it will
> be lower.

any update on this?

best regards,

Martin

Re: [GSOC] State saving performance improvements in MyFaces 2.0

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

Hi

>
> In some parts, facelets uses objects like the one before that are
>> serialized instead implements StateHolder or PartialStateHolder. It could be
>> good to know which strategy is better (serialization or implements
>> PartialStateHolder) and check in which cases it is worth to do it. One
>> example is CompositeComponentBeanInfo, but it could be others as well.
>>
>
> So what you are saying is that in this case it is better to use implements
> PartialStateHolder than serialization? I'll look for more situations where
> serialization is used and we shall discuss whether it is better to use
> PartialStateHolder instead.
>
>
Theorically, the advantage of use PartialStateHolder over serialization, is
that serialization needs to be saved and restored between requests, but
PartialStateHolder objects do not if the inner state is not changed, and if
so, it is necessary to save only the "delta".

Since in jsf we have "StateHolder" and "PartialStateHolder", we are assuming
serializable instances are immutable, so in most cases it is ok to use it.

I checked the code and we are not taking advantage of this assumption on
several places. For example: UIOutput.converter property. Maybe in this
place:

            else if (_isSetConverter() || _converter != null)
            {
                //Full
                converterSaved = saveAttachedState(facesContext,_converter);
                nullDelta = false;
            }

we can do this:

            else if (_isSetConverter() || (_converter != null &&
!(_converter instanceof Serializable) ))
            {
                //Full
                converterSaved = saveAttachedState(facesContext,_converter);
                nullDelta = false;
            }

but I haven't tested it fully yet.

In conclusion, in most cases both strategies are equivalent. But in this
time we don't know which strategy is faster.

For example, let's take the case of CompositeComponentBeanInfo. In theory,
after this object is initialized it does not change between requests (I mean
after the object is returned by vdl.getComponentMetadata(FacesContext,
Resource) ). In theory, PSS algorithm should not save it on the state, so on
each request we are setting it on the first request build. The only case we
have is if we are not using PSS on the current view or on that specific part
of the view by the effect of <c:if> tag. In that case we are
saving/restoring this value and the only relevant criteria to use
PartialStateHolder or serialization is speed.

 problem here is since this call occur in build time, we can't call
> getClientId() (it will cause problems because the parent for most components
> is null in this stage), so use a external map here
>
> Why not use the Reference of the component as the key? Over one request,
> the reference is stable enough!
>
>
Yes, it is possible. Just we have to take care about
ClientBehaviorRedirectEventComponentWrapper, because this class is used as a
wrapper to redirect client behavior events.

Note that CompositeComponentResourceTagHandler.ATTACHED_OBJECT_HADLERS_KEY
list is not saved on the state, but since we use the component attribute
map, the key and the null value is saved on the state. If we don't use the
component attribute map, we don't have that trace on the state and it will
be lower.

best regards,

Leonardo

Re: [GSOC] State saving performance improvements in MyFaces 2.0

Posted by Martin Marinschek <ma...@gmail.com>.

Sent from my phone, so very short:

  problem here is since this call occur in build time, we can't call  
getClientId() (it will cause problems because the parent for most  
components is null in this stage), so use a external map here

Why not use the Reference of the component as the key? Over one  
request, the reference is stable enough!

Best regards,

Martin
>

Re: [GSOC] State saving performance improvements in MyFaces 2.0

Posted by Marius Petoi <ma...@codebeat.ro>.

Hi Leonardo,

Thank you again for your response!

On Mon, Jun 28, 2010 at 11:15 PM, Leonardo Uribe <lu...@gmail.com> wrote:

> Hi Marius
>
> 2010/6/28 Marius Petoi <ma...@codebeat.ro>
>
>> Hello,
>>
>> After looking more to the attributes of the components, here's what I've
>> found regarding state saving:
>>
>> ErrorPageWriter.VISITED_FACET_COUNT - used in the debug page for
>> displaying facet components. It is recalculated at each request, so it is
>> not necessary in the state. My suggestion would be to introduce a map in
>> ErrorPageWriter with number of visited facets for every component
>>
>>
> Yes, sounds good.
>

Then I shall do it like this.

>
>
>> CompositeComponentResourceTagHandler.ATTACHED_OBJECT_HADLERS_KEY - saved
>> in partial state as an attribute. The object is an ArrayList, but my
>> suggestion would be to use instead _DeltaList
>>
>>
> This list is not saved on the state, instead, it is removed on
> CompositeComponentResourceTagHandler.applyNextHandler, because the purpose
> is use it on vdl.retargetAttachedObjects method to apply each of the
> handlers related to the current composite component. The problem here is
> since this call occur in build time, we can't call getClientId() (it will
> cause problems because the parent for most components is null in this
> stage), so use a external map here is not possible. The solution is have a
> transient property map for each component, but we can't do that without a
> change in the spec.
>

OK. So this is not a problem, if you say that it is not saved in the state.

>
>
>
>> ValidatorTagHandlerDelegate.VALIDATOR_ID_EXCLUSION_LIST_KEY - saved in
>> partial state as an attribute. This object is also an ArrayList, that I
>> think should be a _DeltaList instead.
>>
>>
> Yes, it is possible.
>
>
>> InsertChildrenTag.INSERT_CHILDREN_USED, InsertFacetTag.INSERT_FACET_USED -
>> saved in bean if the build is for composite component metadata. Otherwise,
>> saved as a component parameter. When used, these parameters are taken only
>> from the bean. So practically, the value saved in the attribute map is never
>> used...and it is included in the saved state
>>
>>
> Good catch!. It is a mistake. At start
> InsertChildrenTag.INSERT_CHILDREN_USED and InsertFacetTag.INSERT_FACET_USED
> were used to save that information on component state, but that strategy was
> moved to beanDescriptor to allow apply some facelet tags inside a composite
> component first and then the ones inside cc:implementation. I'll remove
> those lines.
>

OK.

>
>
>> Also the list parameters saved in the BeanDescriptor objects in the
>> CompositeComponentBeanInfo are ArrayList-s. But as they are included in the
>> saved state, my suggestion would be to make them _DeltaList-s.
>>
>>
> Note that CompositeComponentBeanInfo implements Externalizable. That means
> this object is serialized, so first that object should implement
> PartialStateHolder.
>
> In theory the algorithm we have, try to cache this object and use it across
> composite components, but this object is serialized/deserialized on each
> save/restore cycle. I think it has sense this object implements
> PartialStateHolder interface.
>
> Thinking about this stuff, I remember one small enhancement I did on
> org.apache.myfaces.view.facelets.tag.jsf.ActionSourceRule. The relevant code
> is this:
>
>         public void applyMetadata(FaceletContext ctx, Object instance)
>         {
>             final MethodExpression methodExpressionOneArg =
> _attr.getMethodExpression(ctx, null, ActionSourceRule.ACTION_LISTENER_SIG);
>             final MethodExpression methodExpressionZeroArg =
> _attr.getMethodExpression(ctx, null, ActionSourceRule.ACTION_SIG);
>             if
> (FaceletCompositionContext.getCurrentInstance(ctx).isUsingPSSOnThisView())
>             {
>                 ((ActionSource2) instance).addActionListener(
>                         new
> PartialMethodExpressionActionListener(methodExpressionOneArg,
> methodExpressionZeroArg));
>             }
>             else
>             {
>                 ((ActionSource2) instance).addActionListener(
>                         new
> MethodExpressionActionListener(methodExpressionOneArg,
> methodExpressionZeroArg));
>             }
>         }
>
> In this case MethodExpressionActionListener implements StateHolder, but
> PartialMethodExpressionActionListener extends MethodExpressionActionListener
> and implements PartialStateHolder. In theory if PSS is used,
> PartialMethodExpressionActionListener is better because it reduce the state
> size.
>
> In some parts, facelets uses objects like the one before that are
> serialized instead implements StateHolder or PartialStateHolder. It could be
> good to know which strategy is better (serialization or implements
> PartialStateHolder) and check in which cases it is worth to do it. One
> example is CompositeComponentBeanInfo, but it could be others as well.
>

So what you are saying is that in this case it is better to use implements
PartialStateHolder than serialization? I'll look for more situations where
serialization is used and we shall discuss whether it is better to use
PartialStateHolder instead.

Also, could please look over the patches when you have the time and tell me
whether there is anything I should do differently.

Thank you!

Regards,
Marius

>
> regards,
>
> Leonardo Uribe
>
> Please tell me if my suggestions are correct. Thank you!
>>
>> Regards,
>> Marius
>>
>>
>> On Mon, Jun 28, 2010 at 11:27 AM, Marius Petoi <ma...@codebeat.ro>wrote:
>>
>>> Hello,
>>>
>>> I created a ticket and attached a patch for removing the MARK_DELETED
>>> attribute from the component. The JIRA ticket is:
>>> https://issues.apache.org/jira/browse/MYFACES-2774. Please have a look
>>> over it and tell me whether I should modify anything.
>>>
>>> Regards,
>>> Marius
>>>
>>>
>>> On Fri, Jun 25, 2010 at 2:12 PM, Marius Petoi <ma...@codebeat.ro>wrote:
>>>
>>>> Hello,
>>>>
>>>> Thank you for the explanations! So, as I see here, it is ok to remove
>>>> the "org.apache.myfaces.view.facelets.MARK_DELETED" attribute from the
>>>> partial state and include it in the FaceletContext (as a list of components
>>>> that are marked for deletion).
>>>>
>>>> Regards,
>>>> Marius
>>>>
>>>>
>>>> On Fri, Jun 25, 2010 at 2:20 AM, Leonardo Uribe <lu...@gmail.com>wrote:
>>>>
>>>>> Hi Martin
>>>>>
>>>>> 2010/6/24 Martin Marinschek <mm...@apache.org>
>>>>>
>>>>> Hi Leonardo,
>>>>>>
>>>>>> > The param "org.apache.myfaces.view.facelets.APPLIED" is used with
>>>>>> the web
>>>>>> > config param javax.faces.FACELETS_REFRESH_PERIOD, to detect changes
>>>>>> on the
>>>>>> > template files. If you set this param to 0, facelets stops to add it
>>>>>> and
>>>>>> > your state size is reduced, so that configuration must be used in
>>>>>> production
>>>>>> > environments.
>>>>>>
>>>>>> so that is in all components? and it is only for reloading? wouldn't
>>>>>> it be enough to have this once per view? In the view-root attributes
>>>>>> map? then, if any of the files which are loaded are younger than this
>>>>>> param, we drop the whole thing and reload? I thought the MARK_APPLIED
>>>>>> was for something else, but I don't remember too well... I am
>>>>>> concerned even about polluting the state while development - it makes
>>>>>> the debugging harder.
>>>>>>
>>>>>
>>>>> MM> so that is in all components?
>>>>>
>>>>> It is applied by DefaultFacelet to the component instance that contains
>>>>> a reference to a template.
>>>>> There are three cases:
>>>>>
>>>>> - When the first facelet is applied (call to Facelet.apply(FacesContext
>>>>> facesContext, UIComponent parent) )
>>>>> - When a composite component template is applied (call to
>>>>> DefaultFacelet.applyCompositeComponent(AbstractFaceletContext ctx,
>>>>> UIComponent parent, Resource resource) )
>>>>> - When a template is included (call to
>>>>> DefaultFacelet.include(AbstractFaceletContext ctx, UIComponent parent, URL
>>>>> url) )
>>>>>
>>>>> So it appears based on how the page use templates or composite
>>>>> components.
>>>>>
>>>>> MM> and it is only for reloading?
>>>>>
>>>>> Yes.
>>>>>
>>>>> MM> wouldn't it be enough to have this once per view? In the view-root
>>>>> attributes map?
>>>>>
>>>>> If we let it just once per view and it is changed a child template, the
>>>>> current view will not be updated because it contains the update time of the
>>>>> base template. It seems possible to use this attribute just once, but to do
>>>>> that it is necessary to change the whole algorithm.
>>>>>
>>>>> MM> if any of the files which are loaded are younger than this param,
>>>>> we drop the whole thing and reload?
>>>>>
>>>>> Looking in deep the current algorithm is not using file modification
>>>>> times as I was expecting (so it does not look for changes), instead it is
>>>>> using as base time the creation time of the Facelet object. So, the
>>>>> algorithm just refresh the templates at specified intervals.
>>>>>
>>>>> It seems we can do something more simple here and do not pollute the
>>>>> state.
>>>>>
>>>>>
>>>>>> > I think it is possible to do something about
>>>>>> ComponentSupport.MARK_DELETED.
>>>>>> > The algorithm used to refresh a view by facelets uses this param to
>>>>>> indicate
>>>>>> > when a component should be deleted, but I think we can rewrite the
>>>>>> algorithm
>>>>>> > to do not use the component attribute map to save this information,
>>>>>> because
>>>>>> > it is only relevant for the current request.
>>>>>>
>>>>>> For even less, right? It should really be valid only for one building
>>>>>> of the view - can we keep it in some facelet-context attribute, keyed
>>>>>> by the component instance (so that the lookup is fast)?
>>>>>>
>>>>>>
>>>>> Yes, that's the idea.
>>>>>
>>>>> best regards,
>>>>>
>>>>> Leonardo
>>>>>
>>>>>
>>>>>>  > Maybe we should change the keys for example from
>>>>>> > "org.apache.myfaces.view.facelets.MARK_DELETED" to something smaller
>>>>>> like
>>>>>> > "oam.facelets.MARK_DELETED" to save some bytes.
>>>>>>
>>>>>> ah well, it should go completely. Everything else is only half the
>>>>>> rent.
>>>>>>
>>>>>> best regards,
>>>>>>
>>>>>> Martin
>>>>>>
>>>>>> > 2010/6/24 Marius Petoi <ma...@codebeat.ro>
>>>>>> >
>>>>>> >> Hello,
>>>>>> >>
>>>>>> >> As you said, Martin, the attribute
>>>>>> >> "org.apache.myfaces.view.facelets.APPLIED" is included in the
>>>>>> partial
>>>>>> >> state.
>>>>>> >> This, as well as all the other attributes of the components, as the
>>>>>> >> attributeMap in the UIComponentBase is a _ComponentAttributesMap.
>>>>>> The put
>>>>>> >> method of this map calls afterwards the method in the
>>>>>> _DeltaStateHelper.
>>>>>> >> This method includes everything in the partial state (as long as
>>>>>> the
>>>>>> >> initial
>>>>>> >> state is marked). This means that all the attributes of a component
>>>>>> will
>>>>>> >> be
>>>>>> >> included in the partial state. I suppose that there are other
>>>>>> attributes
>>>>>> >> as
>>>>>> >> facelets.APPLIED, which don't need to be included in the partial
>>>>>> state.
>>>>>> >>
>>>>>> >> So my suggestion at first would be to add flags to the "put"
>>>>>> methods of
>>>>>> >> the
>>>>>> >> _DeltaStateHelper, in which to decide whether the value added needs
>>>>>> to be
>>>>>> >> in
>>>>>> >> the partial state (and therefore added in the _deltas map), or not
>>>>>> (in
>>>>>> >> which
>>>>>> >> case it will be added only in the _fullstate map). Afterwards, we
>>>>>> should
>>>>>> >> revise all the attributes and decide whether they need to be in the
>>>>>> >> partial
>>>>>> >> state or not and call the put methods with the apropriate flag.
>>>>>> >>
>>>>>> >> What do you think?
>>>>>> >>
>>>>>> >> Regards,
>>>>>> >> Marius
>>>>>> >>
>>>>>> >>
>>>>>> >> On Wed, Jun 23, 2010 at 4:54 PM, Martin Marinschek <
>>>>>> mmarinschek@apache.org
>>>>>> >> > wrote:
>>>>>> >>
>>>>>> >>> Hi Marius,
>>>>>> >>>
>>>>>> >>> I think you will easily find out candidates for a better
>>>>>> >>> implementation - just take a look at the partial state of any of
>>>>>> the
>>>>>> >>> components. Something that comes immediately to my mind is
>>>>>> >>> facelets.MARK_APPLIED - this is only relevant in request-scope,
>>>>>> but is
>>>>>> >>> currently in the partial state, both in Mojarra and MyFaces (last
>>>>>> time
>>>>>> >>> I looked).
>>>>>> >>>
>>>>>> >>> Stuff like this needs to be fixed. Tell us if you have more
>>>>>> information.
>>>>>> >>>
>>>>>> >>> best regards,
>>>>>> >>>
>>>>>> >>> Martin
>>>>>> >>>
>>>>>> >>> On 6/18/10, Leonardo Uribe <lu...@gmail.com> wrote:
>>>>>> >>> > Hi
>>>>>> >>> >
>>>>>> >>> > I think the key classes are UIComponentBase , _DeltaStateHelper
>>>>>> and
>>>>>> >>> > _DeltaList. Take a look at UIComponentBase.saveState() and
>>>>>> >>> > UIComponentBase.restoreState(). Those methods have calls to
>>>>>> other
>>>>>> >>> methods
>>>>>> >>> > that are critical to state saving. I remember UIViewRoot has
>>>>>> other
>>>>>> >>> methods
>>>>>> >>> > too. I think check those classes are a good point to start.
>>>>>> >>> >
>>>>>> >>> > regards,
>>>>>> >>> >
>>>>>> >>> > Leonardo Uribe
>>>>>> >>> >
>>>>>> >>> > 2010/6/18 Marius Petoi <ma...@codebeat.ro>
>>>>>> >>> >
>>>>>> >>> >> Hello,
>>>>>> >>> >>
>>>>>> >>> >> In order to study the current performance of state saving, I
>>>>>> designed
>>>>>> >>> >> a
>>>>>> >>> >> small page that I included in the examples for MyFaces 2.0.
>>>>>> Also, I
>>>>>> >>> wrote
>>>>>> >>> >> 2
>>>>>> >>> >> phase listeners that determine the length of the state saved in
>>>>>> the
>>>>>> >>> >> ExternalContext before the render response phase and before the
>>>>>> >>> >> restore
>>>>>> >>> >> view
>>>>>> >>> >> phase. Do you have any suggestions what components should I
>>>>>> start
>>>>>> >>> >> analyzing
>>>>>> >>> >> the state for?
>>>>>> >>> >>
>>>>>> >>> >> Regards,
>>>>>> >>> >> Marius
>>>>>> >>> >>
>>>>>> >>> >
>>>>>> >>>
>>>>>> >>>
>>>>>> >>> --
>>>>>> >>>
>>>>>> >>> http://www.irian.at
>>>>>> >>>
>>>>>> >>> Your JSF powerhouse -
>>>>>> >>> JSF Consulting, Development and
>>>>>> >>> Courses in English and German
>>>>>> >>>
>>>>>> >>> Professional Support for Apache MyFaces
>>>>>> >>>
>>>>>> >>
>>>>>> >>
>>>>>> >
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> http://www.irian.at
>>>>>>
>>>>>> Your JSF powerhouse -
>>>>>> JSF Consulting, Development and
>>>>>> Courses in English and German
>>>>>>
>>>>>> Professional Support for Apache MyFaces
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [GSOC] State saving performance improvements in MyFaces 2.0

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

Hi Marius

2010/6/28 Marius Petoi <ma...@codebeat.ro>

> Hello,
>
> After looking more to the attributes of the components, here's what I've
> found regarding state saving:
>
> ErrorPageWriter.VISITED_FACET_COUNT - used in the debug page for displaying
> facet components. It is recalculated at each request, so it is not necessary
> in the state. My suggestion would be to introduce a map in ErrorPageWriter
> with number of visited facets for every component
>
>
Yes, sounds good.


> CompositeComponentResourceTagHandler.ATTACHED_OBJECT_HADLERS_KEY - saved in
> partial state as an attribute. The object is an ArrayList, but my suggestion
> would be to use instead _DeltaList
>
>
This list is not saved on the state, instead, it is removed on
CompositeComponentResourceTagHandler.applyNextHandler, because the purpose
is use it on vdl.retargetAttachedObjects method to apply each of the
handlers related to the current composite component. The problem here is
since this call occur in build time, we can't call getClientId() (it will
cause problems because the parent for most components is null in this
stage), so use a external map here is not possible. The solution is have a
transient property map for each component, but we can't do that without a
change in the spec.



> ValidatorTagHandlerDelegate.VALIDATOR_ID_EXCLUSION_LIST_KEY - saved in
> partial state as an attribute. This object is also an ArrayList, that I
> think should be a _DeltaList instead.
>
>
Yes, it is possible.


> InsertChildrenTag.INSERT_CHILDREN_USED, InsertFacetTag.INSERT_FACET_USED -
> saved in bean if the build is for composite component metadata. Otherwise,
> saved as a component parameter. When used, these parameters are taken only
> from the bean. So practically, the value saved in the attribute map is never
> used...and it is included in the saved state
>
>
Good catch!. It is a mistake. At start
InsertChildrenTag.INSERT_CHILDREN_USED and InsertFacetTag.INSERT_FACET_USED
were used to save that information on component state, but that strategy was
moved to beanDescriptor to allow apply some facelet tags inside a composite
component first and then the ones inside cc:implementation. I'll remove
those lines.


> Also the list parameters saved in the BeanDescriptor objects in the
> CompositeComponentBeanInfo are ArrayList-s. But as they are included in the
> saved state, my suggestion would be to make them _DeltaList-s.
>
>
Note that CompositeComponentBeanInfo implements Externalizable. That means
this object is serialized, so first that object should implement
PartialStateHolder.

In theory the algorithm we have, try to cache this object and use it across
composite components, but this object is serialized/deserialized on each
save/restore cycle. I think it has sense this object implements
PartialStateHolder interface.

Thinking about this stuff, I remember one small enhancement I did on
org.apache.myfaces.view.facelets.tag.jsf.ActionSourceRule. The relevant code
is this:

        public void applyMetadata(FaceletContext ctx, Object instance)
        {
            final MethodExpression methodExpressionOneArg =
_attr.getMethodExpression(ctx, null, ActionSourceRule.ACTION_LISTENER_SIG);
            final MethodExpression methodExpressionZeroArg =
_attr.getMethodExpression(ctx, null, ActionSourceRule.ACTION_SIG);
            if
(FaceletCompositionContext.getCurrentInstance(ctx).isUsingPSSOnThisView())
            {
                ((ActionSource2) instance).addActionListener(
                        new
PartialMethodExpressionActionListener(methodExpressionOneArg,
methodExpressionZeroArg));
            }
            else
            {
                ((ActionSource2) instance).addActionListener(
                        new
MethodExpressionActionListener(methodExpressionOneArg,
methodExpressionZeroArg));
            }
        }

In this case MethodExpressionActionListener implements StateHolder, but
PartialMethodExpressionActionListener extends MethodExpressionActionListener
and implements PartialStateHolder. In theory if PSS is used,
PartialMethodExpressionActionListener is better because it reduce the state
size.

In some parts, facelets uses objects like the one before that are serialized
instead implements StateHolder or PartialStateHolder. It could be good to
know which strategy is better (serialization or implements
PartialStateHolder) and check in which cases it is worth to do it. One
example is CompositeComponentBeanInfo, but it could be others as well.

regards,

Leonardo Uribe

Please tell me if my suggestions are correct. Thank you!
>
> Regards,
> Marius
>
>
> On Mon, Jun 28, 2010 at 11:27 AM, Marius Petoi <ma...@codebeat.ro>wrote:
>
>> Hello,
>>
>> I created a ticket and attached a patch for removing the MARK_DELETED
>> attribute from the component. The JIRA ticket is:
>> https://issues.apache.org/jira/browse/MYFACES-2774. Please have a look
>> over it and tell me whether I should modify anything.
>>
>> Regards,
>> Marius
>>
>>
>> On Fri, Jun 25, 2010 at 2:12 PM, Marius Petoi <ma...@codebeat.ro>wrote:
>>
>>> Hello,
>>>
>>> Thank you for the explanations! So, as I see here, it is ok to remove the
>>> "org.apache.myfaces.view.facelets.MARK_DELETED" attribute from the partial
>>> state and include it in the FaceletContext (as a list of components that are
>>> marked for deletion).
>>>
>>> Regards,
>>> Marius
>>>
>>>
>>> On Fri, Jun 25, 2010 at 2:20 AM, Leonardo Uribe <lu...@gmail.com>wrote:
>>>
>>>> Hi Martin
>>>>
>>>> 2010/6/24 Martin Marinschek <mm...@apache.org>
>>>>
>>>> Hi Leonardo,
>>>>>
>>>>> > The param "org.apache.myfaces.view.facelets.APPLIED" is used with the
>>>>> web
>>>>> > config param javax.faces.FACELETS_REFRESH_PERIOD, to detect changes
>>>>> on the
>>>>> > template files. If you set this param to 0, facelets stops to add it
>>>>> and
>>>>> > your state size is reduced, so that configuration must be used in
>>>>> production
>>>>> > environments.
>>>>>
>>>>> so that is in all components? and it is only for reloading? wouldn't
>>>>> it be enough to have this once per view? In the view-root attributes
>>>>> map? then, if any of the files which are loaded are younger than this
>>>>> param, we drop the whole thing and reload? I thought the MARK_APPLIED
>>>>> was for something else, but I don't remember too well... I am
>>>>> concerned even about polluting the state while development - it makes
>>>>> the debugging harder.
>>>>>
>>>>
>>>> MM> so that is in all components?
>>>>
>>>> It is applied by DefaultFacelet to the component instance that contains
>>>> a reference to a template.
>>>> There are three cases:
>>>>
>>>> - When the first facelet is applied (call to Facelet.apply(FacesContext
>>>> facesContext, UIComponent parent) )
>>>> - When a composite component template is applied (call to
>>>> DefaultFacelet.applyCompositeComponent(AbstractFaceletContext ctx,
>>>> UIComponent parent, Resource resource) )
>>>> - When a template is included (call to
>>>> DefaultFacelet.include(AbstractFaceletContext ctx, UIComponent parent, URL
>>>> url) )
>>>>
>>>> So it appears based on how the page use templates or composite
>>>> components.
>>>>
>>>> MM> and it is only for reloading?
>>>>
>>>> Yes.
>>>>
>>>> MM> wouldn't it be enough to have this once per view? In the view-root
>>>> attributes map?
>>>>
>>>> If we let it just once per view and it is changed a child template, the
>>>> current view will not be updated because it contains the update time of the
>>>> base template. It seems possible to use this attribute just once, but to do
>>>> that it is necessary to change the whole algorithm.
>>>>
>>>> MM> if any of the files which are loaded are younger than this param, we
>>>> drop the whole thing and reload?
>>>>
>>>> Looking in deep the current algorithm is not using file modification
>>>> times as I was expecting (so it does not look for changes), instead it is
>>>> using as base time the creation time of the Facelet object. So, the
>>>> algorithm just refresh the templates at specified intervals.
>>>>
>>>> It seems we can do something more simple here and do not pollute the
>>>> state.
>>>>
>>>>
>>>>> > I think it is possible to do something about
>>>>> ComponentSupport.MARK_DELETED.
>>>>> > The algorithm used to refresh a view by facelets uses this param to
>>>>> indicate
>>>>> > when a component should be deleted, but I think we can rewrite the
>>>>> algorithm
>>>>> > to do not use the component attribute map to save this information,
>>>>> because
>>>>> > it is only relevant for the current request.
>>>>>
>>>>> For even less, right? It should really be valid only for one building
>>>>> of the view - can we keep it in some facelet-context attribute, keyed
>>>>> by the component instance (so that the lookup is fast)?
>>>>>
>>>>>
>>>> Yes, that's the idea.
>>>>
>>>> best regards,
>>>>
>>>> Leonardo
>>>>
>>>>
>>>>>  > Maybe we should change the keys for example from
>>>>> > "org.apache.myfaces.view.facelets.MARK_DELETED" to something smaller
>>>>> like
>>>>> > "oam.facelets.MARK_DELETED" to save some bytes.
>>>>>
>>>>> ah well, it should go completely. Everything else is only half the
>>>>> rent.
>>>>>
>>>>> best regards,
>>>>>
>>>>> Martin
>>>>>
>>>>> > 2010/6/24 Marius Petoi <ma...@codebeat.ro>
>>>>> >
>>>>> >> Hello,
>>>>> >>
>>>>> >> As you said, Martin, the attribute
>>>>> >> "org.apache.myfaces.view.facelets.APPLIED" is included in the
>>>>> partial
>>>>> >> state.
>>>>> >> This, as well as all the other attributes of the components, as the
>>>>> >> attributeMap in the UIComponentBase is a _ComponentAttributesMap.
>>>>> The put
>>>>> >> method of this map calls afterwards the method in the
>>>>> _DeltaStateHelper.
>>>>> >> This method includes everything in the partial state (as long as the
>>>>> >> initial
>>>>> >> state is marked). This means that all the attributes of a component
>>>>> will
>>>>> >> be
>>>>> >> included in the partial state. I suppose that there are other
>>>>> attributes
>>>>> >> as
>>>>> >> facelets.APPLIED, which don't need to be included in the partial
>>>>> state.
>>>>> >>
>>>>> >> So my suggestion at first would be to add flags to the "put" methods
>>>>> of
>>>>> >> the
>>>>> >> _DeltaStateHelper, in which to decide whether the value added needs
>>>>> to be
>>>>> >> in
>>>>> >> the partial state (and therefore added in the _deltas map), or not
>>>>> (in
>>>>> >> which
>>>>> >> case it will be added only in the _fullstate map). Afterwards, we
>>>>> should
>>>>> >> revise all the attributes and decide whether they need to be in the
>>>>> >> partial
>>>>> >> state or not and call the put methods with the apropriate flag.
>>>>> >>
>>>>> >> What do you think?
>>>>> >>
>>>>> >> Regards,
>>>>> >> Marius
>>>>> >>
>>>>> >>
>>>>> >> On Wed, Jun 23, 2010 at 4:54 PM, Martin Marinschek <
>>>>> mmarinschek@apache.org
>>>>> >> > wrote:
>>>>> >>
>>>>> >>> Hi Marius,
>>>>> >>>
>>>>> >>> I think you will easily find out candidates for a better
>>>>> >>> implementation - just take a look at the partial state of any of
>>>>> the
>>>>> >>> components. Something that comes immediately to my mind is
>>>>> >>> facelets.MARK_APPLIED - this is only relevant in request-scope, but
>>>>> is
>>>>> >>> currently in the partial state, both in Mojarra and MyFaces (last
>>>>> time
>>>>> >>> I looked).
>>>>> >>>
>>>>> >>> Stuff like this needs to be fixed. Tell us if you have more
>>>>> information.
>>>>> >>>
>>>>> >>> best regards,
>>>>> >>>
>>>>> >>> Martin
>>>>> >>>
>>>>> >>> On 6/18/10, Leonardo Uribe <lu...@gmail.com> wrote:
>>>>> >>> > Hi
>>>>> >>> >
>>>>> >>> > I think the key classes are UIComponentBase , _DeltaStateHelper
>>>>> and
>>>>> >>> > _DeltaList. Take a look at UIComponentBase.saveState() and
>>>>> >>> > UIComponentBase.restoreState(). Those methods have calls to other
>>>>> >>> methods
>>>>> >>> > that are critical to state saving. I remember UIViewRoot has
>>>>> other
>>>>> >>> methods
>>>>> >>> > too. I think check those classes are a good point to start.
>>>>> >>> >
>>>>> >>> > regards,
>>>>> >>> >
>>>>> >>> > Leonardo Uribe
>>>>> >>> >
>>>>> >>> > 2010/6/18 Marius Petoi <ma...@codebeat.ro>
>>>>> >>> >
>>>>> >>> >> Hello,
>>>>> >>> >>
>>>>> >>> >> In order to study the current performance of state saving, I
>>>>> designed
>>>>> >>> >> a
>>>>> >>> >> small page that I included in the examples for MyFaces 2.0.
>>>>> Also, I
>>>>> >>> wrote
>>>>> >>> >> 2
>>>>> >>> >> phase listeners that determine the length of the state saved in
>>>>> the
>>>>> >>> >> ExternalContext before the render response phase and before the
>>>>> >>> >> restore
>>>>> >>> >> view
>>>>> >>> >> phase. Do you have any suggestions what components should I
>>>>> start
>>>>> >>> >> analyzing
>>>>> >>> >> the state for?
>>>>> >>> >>
>>>>> >>> >> Regards,
>>>>> >>> >> Marius
>>>>> >>> >>
>>>>> >>> >
>>>>> >>>
>>>>> >>>
>>>>> >>> --
>>>>> >>>
>>>>> >>> http://www.irian.at
>>>>> >>>
>>>>> >>> Your JSF powerhouse -
>>>>> >>> JSF Consulting, Development and
>>>>> >>> Courses in English and German
>>>>> >>>
>>>>> >>> Professional Support for Apache MyFaces
>>>>> >>>
>>>>> >>
>>>>> >>
>>>>> >
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> http://www.irian.at
>>>>>
>>>>> Your JSF powerhouse -
>>>>> JSF Consulting, Development and
>>>>> Courses in English and German
>>>>>
>>>>> Professional Support for Apache MyFaces
>>>>>
>>>>
>>>>
>>>
>>
>

Re: [GSOC] State saving performance improvements in MyFaces 2.0

Posted by Marius Petoi <ma...@codebeat.ro>.

Hello,

After looking more to the attributes of the components, here's what I've
found regarding state saving:

ErrorPageWriter.VISITED_FACET_COUNT - used in the debug page for displaying
facet components. It is recalculated at each request, so it is not necessary
in the state. My suggestion would be to introduce a map in ErrorPageWriter
with number of visited facets for every component

CompositeComponentResourceTagHandler.ATTACHED_OBJECT_HADLERS_KEY - saved in
partial state as an attribute. The object is an ArrayList, but my suggestion
would be to use instead _DeltaList

ValidatorTagHandlerDelegate.VALIDATOR_ID_EXCLUSION_LIST_KEY - saved in
partial state as an attribute. This object is also an ArrayList, that I
think should be a _DeltaList instead.

InsertChildrenTag.INSERT_CHILDREN_USED, InsertFacetTag.INSERT_FACET_USED -
saved in bean if the build is for composite component metadata. Otherwise,
saved as a component parameter. When used, these parameters are taken only
from the bean. So practically, the value saved in the attribute map is never
used...and it is included in the saved state

Also the list parameters saved in the BeanDescriptor objects in the
CompositeComponentBeanInfo are ArrayList-s. But as they are included in the
saved state, my suggestion would be to make them _DeltaList-s.

Please tell me if my suggestions are correct. Thank you!

Regards,
Marius

On Mon, Jun 28, 2010 at 11:27 AM, Marius Petoi <ma...@codebeat.ro>wrote:

> Hello,
>
> I created a ticket and attached a patch for removing the MARK_DELETED
> attribute from the component. The JIRA ticket is:
> https://issues.apache.org/jira/browse/MYFACES-2774. Please have a look
> over it and tell me whether I should modify anything.
>
> Regards,
> Marius
>
>
> On Fri, Jun 25, 2010 at 2:12 PM, Marius Petoi <ma...@codebeat.ro>wrote:
>
>> Hello,
>>
>> Thank you for the explanations! So, as I see here, it is ok to remove the
>> "org.apache.myfaces.view.facelets.MARK_DELETED" attribute from the partial
>> state and include it in the FaceletContext (as a list of components that are
>> marked for deletion).
>>
>> Regards,
>> Marius
>>
>>
>> On Fri, Jun 25, 2010 at 2:20 AM, Leonardo Uribe <lu...@gmail.com> wrote:
>>
>>> Hi Martin
>>>
>>> 2010/6/24 Martin Marinschek <mm...@apache.org>
>>>
>>> Hi Leonardo,
>>>>
>>>> > The param "org.apache.myfaces.view.facelets.APPLIED" is used with the
>>>> web
>>>> > config param javax.faces.FACELETS_REFRESH_PERIOD, to detect changes on
>>>> the
>>>> > template files. If you set this param to 0, facelets stops to add it
>>>> and
>>>> > your state size is reduced, so that configuration must be used in
>>>> production
>>>> > environments.
>>>>
>>>> so that is in all components? and it is only for reloading? wouldn't
>>>> it be enough to have this once per view? In the view-root attributes
>>>> map? then, if any of the files which are loaded are younger than this
>>>> param, we drop the whole thing and reload? I thought the MARK_APPLIED
>>>> was for something else, but I don't remember too well... I am
>>>> concerned even about polluting the state while development - it makes
>>>> the debugging harder.
>>>>
>>>
>>> MM> so that is in all components?
>>>
>>> It is applied by DefaultFacelet to the component instance that contains a
>>> reference to a template.
>>> There are three cases:
>>>
>>> - When the first facelet is applied (call to Facelet.apply(FacesContext
>>> facesContext, UIComponent parent) )
>>> - When a composite component template is applied (call to
>>> DefaultFacelet.applyCompositeComponent(AbstractFaceletContext ctx,
>>> UIComponent parent, Resource resource) )
>>> - When a template is included (call to
>>> DefaultFacelet.include(AbstractFaceletContext ctx, UIComponent parent, URL
>>> url) )
>>>
>>> So it appears based on how the page use templates or composite
>>> components.
>>>
>>> MM> and it is only for reloading?
>>>
>>> Yes.
>>>
>>> MM> wouldn't it be enough to have this once per view? In the view-root
>>> attributes map?
>>>
>>> If we let it just once per view and it is changed a child template, the
>>> current view will not be updated because it contains the update time of the
>>> base template. It seems possible to use this attribute just once, but to do
>>> that it is necessary to change the whole algorithm.
>>>
>>> MM> if any of the files which are loaded are younger than this param, we
>>> drop the whole thing and reload?
>>>
>>> Looking in deep the current algorithm is not using file modification
>>> times as I was expecting (so it does not look for changes), instead it is
>>> using as base time the creation time of the Facelet object. So, the
>>> algorithm just refresh the templates at specified intervals.
>>>
>>> It seems we can do something more simple here and do not pollute the
>>> state.
>>>
>>>
>>>> > I think it is possible to do something about
>>>> ComponentSupport.MARK_DELETED.
>>>> > The algorithm used to refresh a view by facelets uses this param to
>>>> indicate
>>>> > when a component should be deleted, but I think we can rewrite the
>>>> algorithm
>>>> > to do not use the component attribute map to save this information,
>>>> because
>>>> > it is only relevant for the current request.
>>>>
>>>> For even less, right? It should really be valid only for one building
>>>> of the view - can we keep it in some facelet-context attribute, keyed
>>>> by the component instance (so that the lookup is fast)?
>>>>
>>>>
>>> Yes, that's the idea.
>>>
>>> best regards,
>>>
>>> Leonardo
>>>
>>>
>>>>  > Maybe we should change the keys for example from
>>>> > "org.apache.myfaces.view.facelets.MARK_DELETED" to something smaller
>>>> like
>>>> > "oam.facelets.MARK_DELETED" to save some bytes.
>>>>
>>>> ah well, it should go completely. Everything else is only half the rent.
>>>>
>>>> best regards,
>>>>
>>>> Martin
>>>>
>>>> > 2010/6/24 Marius Petoi <ma...@codebeat.ro>
>>>> >
>>>> >> Hello,
>>>> >>
>>>> >> As you said, Martin, the attribute
>>>> >> "org.apache.myfaces.view.facelets.APPLIED" is included in the partial
>>>> >> state.
>>>> >> This, as well as all the other attributes of the components, as the
>>>> >> attributeMap in the UIComponentBase is a _ComponentAttributesMap. The
>>>> put
>>>> >> method of this map calls afterwards the method in the
>>>> _DeltaStateHelper.
>>>> >> This method includes everything in the partial state (as long as the
>>>> >> initial
>>>> >> state is marked). This means that all the attributes of a component
>>>> will
>>>> >> be
>>>> >> included in the partial state. I suppose that there are other
>>>> attributes
>>>> >> as
>>>> >> facelets.APPLIED, which don't need to be included in the partial
>>>> state.
>>>> >>
>>>> >> So my suggestion at first would be to add flags to the "put" methods
>>>> of
>>>> >> the
>>>> >> _DeltaStateHelper, in which to decide whether the value added needs
>>>> to be
>>>> >> in
>>>> >> the partial state (and therefore added in the _deltas map), or not
>>>> (in
>>>> >> which
>>>> >> case it will be added only in the _fullstate map). Afterwards, we
>>>> should
>>>> >> revise all the attributes and decide whether they need to be in the
>>>> >> partial
>>>> >> state or not and call the put methods with the apropriate flag.
>>>> >>
>>>> >> What do you think?
>>>> >>
>>>> >> Regards,
>>>> >> Marius
>>>> >>
>>>> >>
>>>> >> On Wed, Jun 23, 2010 at 4:54 PM, Martin Marinschek <
>>>> mmarinschek@apache.org
>>>> >> > wrote:
>>>> >>
>>>> >>> Hi Marius,
>>>> >>>
>>>> >>> I think you will easily find out candidates for a better
>>>> >>> implementation - just take a look at the partial state of any of the
>>>> >>> components. Something that comes immediately to my mind is
>>>> >>> facelets.MARK_APPLIED - this is only relevant in request-scope, but
>>>> is
>>>> >>> currently in the partial state, both in Mojarra and MyFaces (last
>>>> time
>>>> >>> I looked).
>>>> >>>
>>>> >>> Stuff like this needs to be fixed. Tell us if you have more
>>>> information.
>>>> >>>
>>>> >>> best regards,
>>>> >>>
>>>> >>> Martin
>>>> >>>
>>>> >>> On 6/18/10, Leonardo Uribe <lu...@gmail.com> wrote:
>>>> >>> > Hi
>>>> >>> >
>>>> >>> > I think the key classes are UIComponentBase , _DeltaStateHelper
>>>> and
>>>> >>> > _DeltaList. Take a look at UIComponentBase.saveState() and
>>>> >>> > UIComponentBase.restoreState(). Those methods have calls to other
>>>> >>> methods
>>>> >>> > that are critical to state saving. I remember UIViewRoot has other
>>>> >>> methods
>>>> >>> > too. I think check those classes are a good point to start.
>>>> >>> >
>>>> >>> > regards,
>>>> >>> >
>>>> >>> > Leonardo Uribe
>>>> >>> >
>>>> >>> > 2010/6/18 Marius Petoi <ma...@codebeat.ro>
>>>> >>> >
>>>> >>> >> Hello,
>>>> >>> >>
>>>> >>> >> In order to study the current performance of state saving, I
>>>> designed
>>>> >>> >> a
>>>> >>> >> small page that I included in the examples for MyFaces 2.0. Also,
>>>> I
>>>> >>> wrote
>>>> >>> >> 2
>>>> >>> >> phase listeners that determine the length of the state saved in
>>>> the
>>>> >>> >> ExternalContext before the render response phase and before the
>>>> >>> >> restore
>>>> >>> >> view
>>>> >>> >> phase. Do you have any suggestions what components should I start
>>>> >>> >> analyzing
>>>> >>> >> the state for?
>>>> >>> >>
>>>> >>> >> Regards,
>>>> >>> >> Marius
>>>> >>> >>
>>>> >>> >
>>>> >>>
>>>> >>>
>>>> >>> --
>>>> >>>
>>>> >>> http://www.irian.at
>>>> >>>
>>>> >>> Your JSF powerhouse -
>>>> >>> JSF Consulting, Development and
>>>> >>> Courses in English and German
>>>> >>>
>>>> >>> Professional Support for Apache MyFaces
>>>> >>>
>>>> >>
>>>> >>
>>>> >
>>>>
>>>>
>>>> --
>>>>
>>>> http://www.irian.at
>>>>
>>>> Your JSF powerhouse -
>>>> JSF Consulting, Development and
>>>> Courses in English and German
>>>>
>>>> Professional Support for Apache MyFaces
>>>>
>>>
>>>
>>
>

Re: [GSOC] State saving performance improvements in MyFaces 2.0

Posted by Marius Petoi <ma...@codebeat.ro>.

Hello,

I created a ticket and attached a patch for removing the MARK_DELETED
attribute from the component. The JIRA ticket is:
https://issues.apache.org/jira/browse/MYFACES-2774. Please have a look over
it and tell me whether I should modify anything.

Regards,
Marius

On Fri, Jun 25, 2010 at 2:12 PM, Marius Petoi <ma...@codebeat.ro>wrote:

> Hello,
>
> Thank you for the explanations! So, as I see here, it is ok to remove the
> "org.apache.myfaces.view.facelets.MARK_DELETED" attribute from the partial
> state and include it in the FaceletContext (as a list of components that are
> marked for deletion).
>
> Regards,
> Marius
>
>
> On Fri, Jun 25, 2010 at 2:20 AM, Leonardo Uribe <lu...@gmail.com> wrote:
>
>> Hi Martin
>>
>> 2010/6/24 Martin Marinschek <mm...@apache.org>
>>
>> Hi Leonardo,
>>>
>>> > The param "org.apache.myfaces.view.facelets.APPLIED" is used with the
>>> web
>>> > config param javax.faces.FACELETS_REFRESH_PERIOD, to detect changes on
>>> the
>>> > template files. If you set this param to 0, facelets stops to add it
>>> and
>>> > your state size is reduced, so that configuration must be used in
>>> production
>>> > environments.
>>>
>>> so that is in all components? and it is only for reloading? wouldn't
>>> it be enough to have this once per view? In the view-root attributes
>>> map? then, if any of the files which are loaded are younger than this
>>> param, we drop the whole thing and reload? I thought the MARK_APPLIED
>>> was for something else, but I don't remember too well... I am
>>> concerned even about polluting the state while development - it makes
>>> the debugging harder.
>>>
>>
>> MM> so that is in all components?
>>
>> It is applied by DefaultFacelet to the component instance that contains a
>> reference to a template.
>> There are three cases:
>>
>> - When the first facelet is applied (call to Facelet.apply(FacesContext
>> facesContext, UIComponent parent) )
>> - When a composite component template is applied (call to
>> DefaultFacelet.applyCompositeComponent(AbstractFaceletContext ctx,
>> UIComponent parent, Resource resource) )
>> - When a template is included (call to
>> DefaultFacelet.include(AbstractFaceletContext ctx, UIComponent parent, URL
>> url) )
>>
>> So it appears based on how the page use templates or composite components.
>>
>> MM> and it is only for reloading?
>>
>> Yes.
>>
>> MM> wouldn't it be enough to have this once per view? In the view-root
>> attributes map?
>>
>> If we let it just once per view and it is changed a child template, the
>> current view will not be updated because it contains the update time of the
>> base template. It seems possible to use this attribute just once, but to do
>> that it is necessary to change the whole algorithm.
>>
>> MM> if any of the files which are loaded are younger than this param, we
>> drop the whole thing and reload?
>>
>> Looking in deep the current algorithm is not using file modification times
>> as I was expecting (so it does not look for changes), instead it is using as
>> base time the creation time of the Facelet object. So, the algorithm just
>> refresh the templates at specified intervals.
>>
>> It seems we can do something more simple here and do not pollute the
>> state.
>>
>>
>>> > I think it is possible to do something about
>>> ComponentSupport.MARK_DELETED.
>>> > The algorithm used to refresh a view by facelets uses this param to
>>> indicate
>>> > when a component should be deleted, but I think we can rewrite the
>>> algorithm
>>> > to do not use the component attribute map to save this information,
>>> because
>>> > it is only relevant for the current request.
>>>
>>> For even less, right? It should really be valid only for one building
>>> of the view - can we keep it in some facelet-context attribute, keyed
>>> by the component instance (so that the lookup is fast)?
>>>
>>>
>> Yes, that's the idea.
>>
>> best regards,
>>
>> Leonardo
>>
>>
>>>  > Maybe we should change the keys for example from
>>> > "org.apache.myfaces.view.facelets.MARK_DELETED" to something smaller
>>> like
>>> > "oam.facelets.MARK_DELETED" to save some bytes.
>>>
>>> ah well, it should go completely. Everything else is only half the rent.
>>>
>>> best regards,
>>>
>>> Martin
>>>
>>> > 2010/6/24 Marius Petoi <ma...@codebeat.ro>
>>> >
>>> >> Hello,
>>> >>
>>> >> As you said, Martin, the attribute
>>> >> "org.apache.myfaces.view.facelets.APPLIED" is included in the partial
>>> >> state.
>>> >> This, as well as all the other attributes of the components, as the
>>> >> attributeMap in the UIComponentBase is a _ComponentAttributesMap. The
>>> put
>>> >> method of this map calls afterwards the method in the
>>> _DeltaStateHelper.
>>> >> This method includes everything in the partial state (as long as the
>>> >> initial
>>> >> state is marked). This means that all the attributes of a component
>>> will
>>> >> be
>>> >> included in the partial state. I suppose that there are other
>>> attributes
>>> >> as
>>> >> facelets.APPLIED, which don't need to be included in the partial
>>> state.
>>> >>
>>> >> So my suggestion at first would be to add flags to the "put" methods
>>> of
>>> >> the
>>> >> _DeltaStateHelper, in which to decide whether the value added needs to
>>> be
>>> >> in
>>> >> the partial state (and therefore added in the _deltas map), or not (in
>>> >> which
>>> >> case it will be added only in the _fullstate map). Afterwards, we
>>> should
>>> >> revise all the attributes and decide whether they need to be in the
>>> >> partial
>>> >> state or not and call the put methods with the apropriate flag.
>>> >>
>>> >> What do you think?
>>> >>
>>> >> Regards,
>>> >> Marius
>>> >>
>>> >>
>>> >> On Wed, Jun 23, 2010 at 4:54 PM, Martin Marinschek <
>>> mmarinschek@apache.org
>>> >> > wrote:
>>> >>
>>> >>> Hi Marius,
>>> >>>
>>> >>> I think you will easily find out candidates for a better
>>> >>> implementation - just take a look at the partial state of any of the
>>> >>> components. Something that comes immediately to my mind is
>>> >>> facelets.MARK_APPLIED - this is only relevant in request-scope, but
>>> is
>>> >>> currently in the partial state, both in Mojarra and MyFaces (last
>>> time
>>> >>> I looked).
>>> >>>
>>> >>> Stuff like this needs to be fixed. Tell us if you have more
>>> information.
>>> >>>
>>> >>> best regards,
>>> >>>
>>> >>> Martin
>>> >>>
>>> >>> On 6/18/10, Leonardo Uribe <lu...@gmail.com> wrote:
>>> >>> > Hi
>>> >>> >
>>> >>> > I think the key classes are UIComponentBase , _DeltaStateHelper and
>>> >>> > _DeltaList. Take a look at UIComponentBase.saveState() and
>>> >>> > UIComponentBase.restoreState(). Those methods have calls to other
>>> >>> methods
>>> >>> > that are critical to state saving. I remember UIViewRoot has other
>>> >>> methods
>>> >>> > too. I think check those classes are a good point to start.
>>> >>> >
>>> >>> > regards,
>>> >>> >
>>> >>> > Leonardo Uribe
>>> >>> >
>>> >>> > 2010/6/18 Marius Petoi <ma...@codebeat.ro>
>>> >>> >
>>> >>> >> Hello,
>>> >>> >>
>>> >>> >> In order to study the current performance of state saving, I
>>> designed
>>> >>> >> a
>>> >>> >> small page that I included in the examples for MyFaces 2.0. Also,
>>> I
>>> >>> wrote
>>> >>> >> 2
>>> >>> >> phase listeners that determine the length of the state saved in
>>> the
>>> >>> >> ExternalContext before the render response phase and before the
>>> >>> >> restore
>>> >>> >> view
>>> >>> >> phase. Do you have any suggestions what components should I start
>>> >>> >> analyzing
>>> >>> >> the state for?
>>> >>> >>
>>> >>> >> Regards,
>>> >>> >> Marius
>>> >>> >>
>>> >>> >
>>> >>>
>>> >>>
>>> >>> --
>>> >>>
>>> >>> http://www.irian.at
>>> >>>
>>> >>> Your JSF powerhouse -
>>> >>> JSF Consulting, Development and
>>> >>> Courses in English and German
>>> >>>
>>> >>> Professional Support for Apache MyFaces
>>> >>>
>>> >>
>>> >>
>>> >
>>>
>>>
>>> --
>>>
>>> http://www.irian.at
>>>
>>> Your JSF powerhouse -
>>> JSF Consulting, Development and
>>> Courses in English and German
>>>
>>> Professional Support for Apache MyFaces
>>>
>>
>>
>

Re: [GSOC] State saving performance improvements in MyFaces 2.0

Posted by Marius Petoi <ma...@codebeat.ro>.

Hello,

Thank you for the explanations! So, as I see here, it is ok to remove the
"org.apache.myfaces.view.facelets.MARK_DELETED" attribute from the partial
state and include it in the FaceletContext (as a list of components that are
marked for deletion).

Regards,
Marius

On Fri, Jun 25, 2010 at 2:20 AM, Leonardo Uribe <lu...@gmail.com> wrote:

> Hi Martin
>
> 2010/6/24 Martin Marinschek <mm...@apache.org>
>
> Hi Leonardo,
>>
>> > The param "org.apache.myfaces.view.facelets.APPLIED" is used with the
>> web
>> > config param javax.faces.FACELETS_REFRESH_PERIOD, to detect changes on
>> the
>> > template files. If you set this param to 0, facelets stops to add it and
>> > your state size is reduced, so that configuration must be used in
>> production
>> > environments.
>>
>> so that is in all components? and it is only for reloading? wouldn't
>> it be enough to have this once per view? In the view-root attributes
>> map? then, if any of the files which are loaded are younger than this
>> param, we drop the whole thing and reload? I thought the MARK_APPLIED
>> was for something else, but I don't remember too well... I am
>> concerned even about polluting the state while development - it makes
>> the debugging harder.
>>
>
> MM> so that is in all components?
>
> It is applied by DefaultFacelet to the component instance that contains a
> reference to a template.
> There are three cases:
>
> - When the first facelet is applied (call to Facelet.apply(FacesContext
> facesContext, UIComponent parent) )
> - When a composite component template is applied (call to
> DefaultFacelet.applyCompositeComponent(AbstractFaceletContext ctx,
> UIComponent parent, Resource resource) )
> - When a template is included (call to
> DefaultFacelet.include(AbstractFaceletContext ctx, UIComponent parent, URL
> url) )
>
> So it appears based on how the page use templates or composite components.
>
> MM> and it is only for reloading?
>
> Yes.
>
> MM> wouldn't it be enough to have this once per view? In the view-root
> attributes map?
>
> If we let it just once per view and it is changed a child template, the
> current view will not be updated because it contains the update time of the
> base template. It seems possible to use this attribute just once, but to do
> that it is necessary to change the whole algorithm.
>
> MM> if any of the files which are loaded are younger than this param, we
> drop the whole thing and reload?
>
> Looking in deep the current algorithm is not using file modification times
> as I was expecting (so it does not look for changes), instead it is using as
> base time the creation time of the Facelet object. So, the algorithm just
> refresh the templates at specified intervals.
>
> It seems we can do something more simple here and do not pollute the state.
>
>
>
>> > I think it is possible to do something about
>> ComponentSupport.MARK_DELETED.
>> > The algorithm used to refresh a view by facelets uses this param to
>> indicate
>> > when a component should be deleted, but I think we can rewrite the
>> algorithm
>> > to do not use the component attribute map to save this information,
>> because
>> > it is only relevant for the current request.
>>
>> For even less, right? It should really be valid only for one building
>> of the view - can we keep it in some facelet-context attribute, keyed
>> by the component instance (so that the lookup is fast)?
>>
>>
> Yes, that's the idea.
>
> best regards,
>
> Leonardo
>
>
>>  > Maybe we should change the keys for example from
>> > "org.apache.myfaces.view.facelets.MARK_DELETED" to something smaller
>> like
>> > "oam.facelets.MARK_DELETED" to save some bytes.
>>
>> ah well, it should go completely. Everything else is only half the rent.
>>
>> best regards,
>>
>> Martin
>>
>> > 2010/6/24 Marius Petoi <ma...@codebeat.ro>
>> >
>> >> Hello,
>> >>
>> >> As you said, Martin, the attribute
>> >> "org.apache.myfaces.view.facelets.APPLIED" is included in the partial
>> >> state.
>> >> This, as well as all the other attributes of the components, as the
>> >> attributeMap in the UIComponentBase is a _ComponentAttributesMap. The
>> put
>> >> method of this map calls afterwards the method in the
>> _DeltaStateHelper.
>> >> This method includes everything in the partial state (as long as the
>> >> initial
>> >> state is marked). This means that all the attributes of a component
>> will
>> >> be
>> >> included in the partial state. I suppose that there are other
>> attributes
>> >> as
>> >> facelets.APPLIED, which don't need to be included in the partial state.
>> >>
>> >> So my suggestion at first would be to add flags to the "put" methods of
>> >> the
>> >> _DeltaStateHelper, in which to decide whether the value added needs to
>> be
>> >> in
>> >> the partial state (and therefore added in the _deltas map), or not (in
>> >> which
>> >> case it will be added only in the _fullstate map). Afterwards, we
>> should
>> >> revise all the attributes and decide whether they need to be in the
>> >> partial
>> >> state or not and call the put methods with the apropriate flag.
>> >>
>> >> What do you think?
>> >>
>> >> Regards,
>> >> Marius
>> >>
>> >>
>> >> On Wed, Jun 23, 2010 at 4:54 PM, Martin Marinschek <
>> mmarinschek@apache.org
>> >> > wrote:
>> >>
>> >>> Hi Marius,
>> >>>
>> >>> I think you will easily find out candidates for a better
>> >>> implementation - just take a look at the partial state of any of the
>> >>> components. Something that comes immediately to my mind is
>> >>> facelets.MARK_APPLIED - this is only relevant in request-scope, but is
>> >>> currently in the partial state, both in Mojarra and MyFaces (last time
>> >>> I looked).
>> >>>
>> >>> Stuff like this needs to be fixed. Tell us if you have more
>> information.
>> >>>
>> >>> best regards,
>> >>>
>> >>> Martin
>> >>>
>> >>> On 6/18/10, Leonardo Uribe <lu...@gmail.com> wrote:
>> >>> > Hi
>> >>> >
>> >>> > I think the key classes are UIComponentBase , _DeltaStateHelper and
>> >>> > _DeltaList. Take a look at UIComponentBase.saveState() and
>> >>> > UIComponentBase.restoreState(). Those methods have calls to other
>> >>> methods
>> >>> > that are critical to state saving. I remember UIViewRoot has other
>> >>> methods
>> >>> > too. I think check those classes are a good point to start.
>> >>> >
>> >>> > regards,
>> >>> >
>> >>> > Leonardo Uribe
>> >>> >
>> >>> > 2010/6/18 Marius Petoi <ma...@codebeat.ro>
>> >>> >
>> >>> >> Hello,
>> >>> >>
>> >>> >> In order to study the current performance of state saving, I
>> designed
>> >>> >> a
>> >>> >> small page that I included in the examples for MyFaces 2.0. Also, I
>> >>> wrote
>> >>> >> 2
>> >>> >> phase listeners that determine the length of the state saved in the
>> >>> >> ExternalContext before the render response phase and before the
>> >>> >> restore
>> >>> >> view
>> >>> >> phase. Do you have any suggestions what components should I start
>> >>> >> analyzing
>> >>> >> the state for?
>> >>> >>
>> >>> >> Regards,
>> >>> >> Marius
>> >>> >>
>> >>> >
>> >>>
>> >>>
>> >>> --
>> >>>
>> >>> http://www.irian.at
>> >>>
>> >>> Your JSF powerhouse -
>> >>> JSF Consulting, Development and
>> >>> Courses in English and German
>> >>>
>> >>> Professional Support for Apache MyFaces
>> >>>
>> >>
>> >>
>> >
>>
>>
>> --
>>
>> http://www.irian.at
>>
>> Your JSF powerhouse -
>> JSF Consulting, Development and
>> Courses in English and German
>>
>> Professional Support for Apache MyFaces
>>
>
>

Re: [GSOC] State saving performance improvements in MyFaces 2.0

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

Hi Martin

2010/6/24 Martin Marinschek <mm...@apache.org>

> Hi Leonardo,
>
> > The param "org.apache.myfaces.view.facelets.APPLIED" is used with the web
> > config param javax.faces.FACELETS_REFRESH_PERIOD, to detect changes on
> the
> > template files. If you set this param to 0, facelets stops to add it and
> > your state size is reduced, so that configuration must be used in
> production
> > environments.
>
> so that is in all components? and it is only for reloading? wouldn't
> it be enough to have this once per view? In the view-root attributes
> map? then, if any of the files which are loaded are younger than this
> param, we drop the whole thing and reload? I thought the MARK_APPLIED
> was for something else, but I don't remember too well... I am
> concerned even about polluting the state while development - it makes
> the debugging harder.
>

MM> so that is in all components?

It is applied by DefaultFacelet to the component instance that contains a
reference to a template.
There are three cases:

- When the first facelet is applied (call to Facelet.apply(FacesContext
facesContext, UIComponent parent) )
- When a composite component template is applied (call to
DefaultFacelet.applyCompositeComponent(AbstractFaceletContext ctx,
UIComponent parent, Resource resource) )
- When a template is included (call to
DefaultFacelet.include(AbstractFaceletContext ctx, UIComponent parent, URL
url) )

So it appears based on how the page use templates or composite components.

MM> and it is only for reloading?

Yes.

MM> wouldn't it be enough to have this once per view? In the view-root
attributes map?

If we let it just once per view and it is changed a child template, the
current view will not be updated because it contains the update time of the
base template. It seems possible to use this attribute just once, but to do
that it is necessary to change the whole algorithm.

MM> if any of the files which are loaded are younger than this param, we
drop the whole thing and reload?

Looking in deep the current algorithm is not using file modification times
as I was expecting (so it does not look for changes), instead it is using as
base time the creation time of the Facelet object. So, the algorithm just
refresh the templates at specified intervals.

It seems we can do something more simple here and do not pollute the state.


> > I think it is possible to do something about
> ComponentSupport.MARK_DELETED.
> > The algorithm used to refresh a view by facelets uses this param to
> indicate
> > when a component should be deleted, but I think we can rewrite the
> algorithm
> > to do not use the component attribute map to save this information,
> because
> > it is only relevant for the current request.
>
> For even less, right? It should really be valid only for one building
> of the view - can we keep it in some facelet-context attribute, keyed
> by the component instance (so that the lookup is fast)?
>
>
Yes, that's the idea.

best regards,

Leonardo


> > Maybe we should change the keys for example from
> > "org.apache.myfaces.view.facelets.MARK_DELETED" to something smaller like
> > "oam.facelets.MARK_DELETED" to save some bytes.
>
> ah well, it should go completely. Everything else is only half the rent.
>
> best regards,
>
> Martin
>
> > 2010/6/24 Marius Petoi <ma...@codebeat.ro>
> >
> >> Hello,
> >>
> >> As you said, Martin, the attribute
> >> "org.apache.myfaces.view.facelets.APPLIED" is included in the partial
> >> state.
> >> This, as well as all the other attributes of the components, as the
> >> attributeMap in the UIComponentBase is a _ComponentAttributesMap. The
> put
> >> method of this map calls afterwards the method in the _DeltaStateHelper.
> >> This method includes everything in the partial state (as long as the
> >> initial
> >> state is marked). This means that all the attributes of a component will
> >> be
> >> included in the partial state. I suppose that there are other attributes
> >> as
> >> facelets.APPLIED, which don't need to be included in the partial state.
> >>
> >> So my suggestion at first would be to add flags to the "put" methods of
> >> the
> >> _DeltaStateHelper, in which to decide whether the value added needs to
> be
> >> in
> >> the partial state (and therefore added in the _deltas map), or not (in
> >> which
> >> case it will be added only in the _fullstate map). Afterwards, we should
> >> revise all the attributes and decide whether they need to be in the
> >> partial
> >> state or not and call the put methods with the apropriate flag.
> >>
> >> What do you think?
> >>
> >> Regards,
> >> Marius
> >>
> >>
> >> On Wed, Jun 23, 2010 at 4:54 PM, Martin Marinschek <
> mmarinschek@apache.org
> >> > wrote:
> >>
> >>> Hi Marius,
> >>>
> >>> I think you will easily find out candidates for a better
> >>> implementation - just take a look at the partial state of any of the
> >>> components. Something that comes immediately to my mind is
> >>> facelets.MARK_APPLIED - this is only relevant in request-scope, but is
> >>> currently in the partial state, both in Mojarra and MyFaces (last time
> >>> I looked).
> >>>
> >>> Stuff like this needs to be fixed. Tell us if you have more
> information.
> >>>
> >>> best regards,
> >>>
> >>> Martin
> >>>
> >>> On 6/18/10, Leonardo Uribe <lu...@gmail.com> wrote:
> >>> > Hi
> >>> >
> >>> > I think the key classes are UIComponentBase , _DeltaStateHelper and
> >>> > _DeltaList. Take a look at UIComponentBase.saveState() and
> >>> > UIComponentBase.restoreState(). Those methods have calls to other
> >>> methods
> >>> > that are critical to state saving. I remember UIViewRoot has other
> >>> methods
> >>> > too. I think check those classes are a good point to start.
> >>> >
> >>> > regards,
> >>> >
> >>> > Leonardo Uribe
> >>> >
> >>> > 2010/6/18 Marius Petoi <ma...@codebeat.ro>
> >>> >
> >>> >> Hello,
> >>> >>
> >>> >> In order to study the current performance of state saving, I
> designed
> >>> >> a
> >>> >> small page that I included in the examples for MyFaces 2.0. Also, I
> >>> wrote
> >>> >> 2
> >>> >> phase listeners that determine the length of the state saved in the
> >>> >> ExternalContext before the render response phase and before the
> >>> >> restore
> >>> >> view
> >>> >> phase. Do you have any suggestions what components should I start
> >>> >> analyzing
> >>> >> the state for?
> >>> >>
> >>> >> Regards,
> >>> >> Marius
> >>> >>
> >>> >
> >>>
> >>>
> >>> --
> >>>
> >>> http://www.irian.at
> >>>
> >>> Your JSF powerhouse -
> >>> JSF Consulting, Development and
> >>> Courses in English and German
> >>>
> >>> Professional Support for Apache MyFaces
> >>>
> >>
> >>
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>

Re: [GSOC] State saving performance improvements in MyFaces 2.0

Posted by Martin Marinschek <mm...@apache.org>.

Hi Leonardo,

> The param "org.apache.myfaces.view.facelets.APPLIED" is used with the web
> config param javax.faces.FACELETS_REFRESH_PERIOD, to detect changes on the
> template files. If you set this param to 0, facelets stops to add it and
> your state size is reduced, so that configuration must be used in production
> environments.

so that is in all components? and it is only for reloading? wouldn't
it be enough to have this once per view? In the view-root attributes
map? then, if any of the files which are loaded are younger than this
param, we drop the whole thing and reload? I thought the MARK_APPLIED
was for something else, but I don't remember too well... I am
concerned even about polluting the state while development - it makes
the debugging harder.

> I think it is possible to do something about ComponentSupport.MARK_DELETED.
> The algorithm used to refresh a view by facelets uses this param to indicate
> when a component should be deleted, but I think we can rewrite the algorithm
> to do not use the component attribute map to save this information, because
> it is only relevant for the current request.

For even less, right? It should really be valid only for one building
of the view - can we keep it in some facelet-context attribute, keyed
by the component instance (so that the lookup is fast)?

> Maybe we should change the keys for example from
> "org.apache.myfaces.view.facelets.MARK_DELETED" to something smaller like
> "oam.facelets.MARK_DELETED" to save some bytes.

ah well, it should go completely. Everything else is only half the rent.

best regards,

Martin

> 2010/6/24 Marius Petoi <ma...@codebeat.ro>
>
>> Hello,
>>
>> As you said, Martin, the attribute
>> "org.apache.myfaces.view.facelets.APPLIED" is included in the partial
>> state.
>> This, as well as all the other attributes of the components, as the
>> attributeMap in the UIComponentBase is a _ComponentAttributesMap. The put
>> method of this map calls afterwards the method in the _DeltaStateHelper.
>> This method includes everything in the partial state (as long as the
>> initial
>> state is marked). This means that all the attributes of a component will
>> be
>> included in the partial state. I suppose that there are other attributes
>> as
>> facelets.APPLIED, which don't need to be included in the partial state.
>>
>> So my suggestion at first would be to add flags to the "put" methods of
>> the
>> _DeltaStateHelper, in which to decide whether the value added needs to be
>> in
>> the partial state (and therefore added in the _deltas map), or not (in
>> which
>> case it will be added only in the _fullstate map). Afterwards, we should
>> revise all the attributes and decide whether they need to be in the
>> partial
>> state or not and call the put methods with the apropriate flag.
>>
>> What do you think?
>>
>> Regards,
>> Marius
>>
>>
>> On Wed, Jun 23, 2010 at 4:54 PM, Martin Marinschek <mmarinschek@apache.org
>> > wrote:
>>
>>> Hi Marius,
>>>
>>> I think you will easily find out candidates for a better
>>> implementation - just take a look at the partial state of any of the
>>> components. Something that comes immediately to my mind is
>>> facelets.MARK_APPLIED - this is only relevant in request-scope, but is
>>> currently in the partial state, both in Mojarra and MyFaces (last time
>>> I looked).
>>>
>>> Stuff like this needs to be fixed. Tell us if you have more information.
>>>
>>> best regards,
>>>
>>> Martin
>>>
>>> On 6/18/10, Leonardo Uribe <lu...@gmail.com> wrote:
>>> > Hi
>>> >
>>> > I think the key classes are UIComponentBase , _DeltaStateHelper and
>>> > _DeltaList. Take a look at UIComponentBase.saveState() and
>>> > UIComponentBase.restoreState(). Those methods have calls to other
>>> methods
>>> > that are critical to state saving. I remember UIViewRoot has other
>>> methods
>>> > too. I think check those classes are a good point to start.
>>> >
>>> > regards,
>>> >
>>> > Leonardo Uribe
>>> >
>>> > 2010/6/18 Marius Petoi <ma...@codebeat.ro>
>>> >
>>> >> Hello,
>>> >>
>>> >> In order to study the current performance of state saving, I designed
>>> >> a
>>> >> small page that I included in the examples for MyFaces 2.0. Also, I
>>> wrote
>>> >> 2
>>> >> phase listeners that determine the length of the state saved in the
>>> >> ExternalContext before the render response phase and before the
>>> >> restore
>>> >> view
>>> >> phase. Do you have any suggestions what components should I start
>>> >> analyzing
>>> >> the state for?
>>> >>
>>> >> Regards,
>>> >> Marius
>>> >>
>>> >
>>>
>>>
>>> --
>>>
>>> http://www.irian.at
>>>
>>> Your JSF powerhouse -
>>> JSF Consulting, Development and
>>> Courses in English and German
>>>
>>> Professional Support for Apache MyFaces
>>>
>>
>>
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: [GSOC] State saving performance improvements in MyFaces 2.0

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

Hi

The param "org.apache.myfaces.view.facelets.APPLIED" is used with the web
config param javax.faces.FACELETS_REFRESH_PERIOD, to detect changes on the
template files. If you set this param to 0, facelets stops to add it and
your state size is reduced, so that configuration must be used in production
environments.

I think it is possible to do something about ComponentSupport.MARK_DELETED.
The algorithm used to refresh a view by facelets uses this param to indicate
when a component should be deleted, but I think we can rewrite the algorithm
to do not use the component attribute map to save this information, because
it is only relevant for the current request.

Maybe we should change the keys for example from
"org.apache.myfaces.view.facelets.MARK_DELETED" to something smaller like
"oam.facelets.MARK_DELETED" to save some bytes.

regards,

Leonardo Uribe

2010/6/24 Marius Petoi <ma...@codebeat.ro>

> Hello,
>
> As you said, Martin, the attribute
> "org.apache.myfaces.view.facelets.APPLIED" is included in the partial state.
> This, as well as all the other attributes of the components, as the
> attributeMap in the UIComponentBase is a _ComponentAttributesMap. The put
> method of this map calls afterwards the method in the _DeltaStateHelper.
> This method includes everything in the partial state (as long as the initial
> state is marked). This means that all the attributes of a component will be
> included in the partial state. I suppose that there are other attributes as
> facelets.APPLIED, which don't need to be included in the partial state.
>
> So my suggestion at first would be to add flags to the "put" methods of the
> _DeltaStateHelper, in which to decide whether the value added needs to be in
> the partial state (and therefore added in the _deltas map), or not (in which
> case it will be added only in the _fullstate map). Afterwards, we should
> revise all the attributes and decide whether they need to be in the partial
> state or not and call the put methods with the apropriate flag.
>
> What do you think?
>
> Regards,
> Marius
>
>
> On Wed, Jun 23, 2010 at 4:54 PM, Martin Marinschek <mmarinschek@apache.org
> > wrote:
>
>> Hi Marius,
>>
>> I think you will easily find out candidates for a better
>> implementation - just take a look at the partial state of any of the
>> components. Something that comes immediately to my mind is
>> facelets.MARK_APPLIED - this is only relevant in request-scope, but is
>> currently in the partial state, both in Mojarra and MyFaces (last time
>> I looked).
>>
>> Stuff like this needs to be fixed. Tell us if you have more information.
>>
>> best regards,
>>
>> Martin
>>
>> On 6/18/10, Leonardo Uribe <lu...@gmail.com> wrote:
>> > Hi
>> >
>> > I think the key classes are UIComponentBase , _DeltaStateHelper and
>> > _DeltaList. Take a look at UIComponentBase.saveState() and
>> > UIComponentBase.restoreState(). Those methods have calls to other
>> methods
>> > that are critical to state saving. I remember UIViewRoot has other
>> methods
>> > too. I think check those classes are a good point to start.
>> >
>> > regards,
>> >
>> > Leonardo Uribe
>> >
>> > 2010/6/18 Marius Petoi <ma...@codebeat.ro>
>> >
>> >> Hello,
>> >>
>> >> In order to study the current performance of state saving, I designed a
>> >> small page that I included in the examples for MyFaces 2.0. Also, I
>> wrote
>> >> 2
>> >> phase listeners that determine the length of the state saved in the
>> >> ExternalContext before the render response phase and before the restore
>> >> view
>> >> phase. Do you have any suggestions what components should I start
>> >> analyzing
>> >> the state for?
>> >>
>> >> Regards,
>> >> Marius
>> >>
>> >
>>
>>
>> --
>>
>> http://www.irian.at
>>
>> Your JSF powerhouse -
>> JSF Consulting, Development and
>> Courses in English and German
>>
>> Professional Support for Apache MyFaces
>>
>
>

Re: [GSOC] State saving performance improvements in MyFaces 2.0

Posted by Marius Petoi <ma...@codebeat.ro>.

Hello,

As you said, Martin, the attribute
"org.apache.myfaces.view.facelets.APPLIED" is included in the partial state.
This, as well as all the other attributes of the components, as the
attributeMap in the UIComponentBase is a _ComponentAttributesMap. The put
method of this map calls afterwards the method in the _DeltaStateHelper.
This method includes everything in the partial state (as long as the initial
state is marked). This means that all the attributes of a component will be
included in the partial state. I suppose that there are other attributes as
facelets.APPLIED, which don't need to be included in the partial state.

So my suggestion at first would be to add flags to the "put" methods of the
_DeltaStateHelper, in which to decide whether the value added needs to be in
the partial state (and therefore added in the _deltas map), or not (in which
case it will be added only in the _fullstate map). Afterwards, we should
revise all the attributes and decide whether they need to be in the partial
state or not and call the put methods with the apropriate flag.

What do you think?

Regards,
Marius

On Wed, Jun 23, 2010 at 4:54 PM, Martin Marinschek
<mm...@apache.org>wrote:

> Hi Marius,
>
> I think you will easily find out candidates for a better
> implementation - just take a look at the partial state of any of the
> components. Something that comes immediately to my mind is
> facelets.MARK_APPLIED - this is only relevant in request-scope, but is
> currently in the partial state, both in Mojarra and MyFaces (last time
> I looked).
>
> Stuff like this needs to be fixed. Tell us if you have more information.
>
> best regards,
>
> Martin
>
> On 6/18/10, Leonardo Uribe <lu...@gmail.com> wrote:
> > Hi
> >
> > I think the key classes are UIComponentBase , _DeltaStateHelper and
> > _DeltaList. Take a look at UIComponentBase.saveState() and
> > UIComponentBase.restoreState(). Those methods have calls to other methods
> > that are critical to state saving. I remember UIViewRoot has other
> methods
> > too. I think check those classes are a good point to start.
> >
> > regards,
> >
> > Leonardo Uribe
> >
> > 2010/6/18 Marius Petoi <ma...@codebeat.ro>
> >
> >> Hello,
> >>
> >> In order to study the current performance of state saving, I designed a
> >> small page that I included in the examples for MyFaces 2.0. Also, I
> wrote
> >> 2
> >> phase listeners that determine the length of the state saved in the
> >> ExternalContext before the render response phase and before the restore
> >> view
> >> phase. Do you have any suggestions what components should I start
> >> analyzing
> >> the state for?
> >>
> >> Regards,
> >> Marius
> >>
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>

Re: [GSOC] State saving performance improvements in MyFaces 2.0

Posted by Martin Marinschek <mm...@apache.org>.

Hi Marius,

I think you will easily find out candidates for a better
implementation - just take a look at the partial state of any of the
components. Something that comes immediately to my mind is
facelets.MARK_APPLIED - this is only relevant in request-scope, but is
currently in the partial state, both in Mojarra and MyFaces (last time
I looked).

Stuff like this needs to be fixed. Tell us if you have more information.

best regards,

Martin

On 6/18/10, Leonardo Uribe <lu...@gmail.com> wrote:
> Hi
>
> I think the key classes are UIComponentBase , _DeltaStateHelper and
> _DeltaList. Take a look at UIComponentBase.saveState() and
> UIComponentBase.restoreState(). Those methods have calls to other methods
> that are critical to state saving. I remember UIViewRoot has other methods
> too. I think check those classes are a good point to start.
>
> regards,
>
> Leonardo Uribe
>
> 2010/6/18 Marius Petoi <ma...@codebeat.ro>
>
>> Hello,
>>
>> In order to study the current performance of state saving, I designed a
>> small page that I included in the examples for MyFaces 2.0. Also, I wrote
>> 2
>> phase listeners that determine the length of the state saved in the
>> ExternalContext before the render response phase and before the restore
>> view
>> phase. Do you have any suggestions what components should I start
>> analyzing
>> the state for?
>>
>> Regards,
>> Marius
>>
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: [GSOC] State saving performance improvements in MyFaces 2.0

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

Hi

I think the key classes are UIComponentBase , _DeltaStateHelper and
_DeltaList. Take a look at UIComponentBase.saveState() and
UIComponentBase.restoreState(). Those methods have calls to other methods
that are critical to state saving. I remember UIViewRoot has other methods
too. I think check those classes are a good point to start.

regards,

Leonardo Uribe

2010/6/18 Marius Petoi <ma...@codebeat.ro>

> Hello,
>
> In order to study the current performance of state saving, I designed a
> small page that I included in the examples for MyFaces 2.0. Also, I wrote 2
> phase listeners that determine the length of the state saved in the
> ExternalContext before the render response phase and before the restore view
> phase. Do you have any suggestions what components should I start analyzing
> the state for?
>
> Regards,
> Marius
>