You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Martin Koci <ma...@gmail.com> on 2010/10/20 15:54:51 UTC
[core] performance: TagAttributeImpl and composite component EL
detection
Hi,
a issue to consider in
org.apache.myfaces.view.facelets.tag.TagAttributeImpl:
Methods
TagAttributeImpl.getMethodExpression and
TagAttributeImpl.getValueExpression use
CompositeComponentELUtils.isCompositeComponentXYZ methods to detect if
current #{} contains cc expression. But consider following: if user
migrates from facelets 1.2 to 2.0, this new cc detection slows down
build view process. In one my test case VDL.buildView calls
CompositeComponentELUtils.isCompositeComponentXYZ approx 3000 times per
build view with no match. isCompositeComponentXYZ is not cheap method
because it uses Pattern.matches().
Are there possibilities to avoid this? For example is possible have some
kind of "isProcessingCompositeComponent" method and skip
Pattern.matches() if false? We are in VDL.buildView here and no
components are available yet, no use of methods like
UIComponent.isCompositeComponent(UIComponent) is possible.
Any ideas?
Regards,
Kočičák
Re: [core] performance: TagAttributeImpl and composite component EL detection
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi Jakob
2010/10/20 Jakob Korherr <ja...@gmail.com>
> Hi Leo,
>
> Hehe, yes, great idea!! I am wondering why we did not think of that in
> the first place...
>
> However one question - why are you using the approach with one integer
> instead of three booleans? I know it's only a question about code
> style, but it kinda seems odd.
>
>
TagAttributeImpl class is created many times, so I'm just doing the same as
trinidad PropertyKey.
regards,
Leonardo
> Regards,
> Jakob
>
> 2010/10/20 Leonardo Uribe <lu...@gmail.com>:
> > Hi
> >
> > I have an idea: why don't evaluate that condition on construction time?
> >
> > In that case, EL will be scanned only once (when the Facelet or Abstract
> > Syntax Tree (AST) is build) and
> > not when the view is build, like is happening now.
> >
> > I have created an issue
> >
> > https://issues.apache.org/jira/browse/MYFACES-2951
> >
> > and committed the code in trunk.
> >
> > Suggestions are welcome.
> >
> > Leonardo Uribe
> >
> > 2010/10/20 Jakob Korherr <ja...@gmail.com>
> >>
> >> Hi Kočičák,
> >>
> >> There might be some ways to improve this, but we have to be very
> >> careful in making changes to that area, because the whole composite
> >> components + EL domain is not that easy.
> >>
> >> Actually the CompositeComponentELUtils.isCompositeComponentXYZ methods
> >> were introduced by myself when fixing the #{cc} issues we encountered
> >> in some MyFaces 2 alpha versions. Unfortunately I currently don't
> >> really have time to think about improvements here, sorry. But I really
> >> think that there is some room for improvements!
> >>
> >> Also I really like your idea of isProcessingCompositeComponent. This
> >> might be a good way, because if this is false we can skip the #{cc}
> >> check, because such expressions will certainly not occur outside of a
> >> composite component. If you have some spare time, a patch would be
> >> really great :) :) - otherwise please just open a JIRA issue for this
> >> one so that we don't loose sight of it. Thanks!
> >>
> >> Regards,
> >> Jakob
> >>
> >> 2010/10/20 Werner Punz <we...@gmail.com>:
> >> > Just my 2c without looking into the code, but I assume speed
> >> > improvements
> >> > already can be gained by replacing the pattern matches, if possible
> with
> >> > a
> >> > direct ll comparison.
> >> > Regexps often are heavier than simple parsing or string operations.
> >> >
> >> > Another thing might be that we add some caching mechanism on this
> level
> >> > which caches per request if possible. But I have not looked into the
> >> > code,
> >> > so I am making wild assumptions here.
> >> >
> >> > I assume also that some speed still can be gained in this area by
> better
> >> > utilization of the improved tree walking api jsf2 provides.
> >> >
> >> >
> >> > Werner
> >> >
> >> >
> >> > Am 20.10.10 15:54, schrieb Martin Koci:
> >> >>
> >> >> Hi,
> >> >>
> >> >>
> >> >> a issue to consider in
> >> >> org.apache.myfaces.view.facelets.tag.TagAttributeImpl:
> >> >>
> >> >>
> >> >> Methods
> >> >> TagAttributeImpl.getMethodExpression and
> >> >> TagAttributeImpl.getValueExpression use
> >> >> CompositeComponentELUtils.isCompositeComponentXYZ methods to detect
> if
> >> >> current #{} contains cc expression. But consider following: if user
> >> >> migrates from facelets 1.2 to 2.0, this new cc detection slows down
> >> >> build view process. In one my test case VDL.buildView calls
> >> >> CompositeComponentELUtils.isCompositeComponentXYZ approx 3000 times
> per
> >> >> build view with no match. isCompositeComponentXYZ is not cheap method
> >> >> because it uses Pattern.matches().
> >> >>
> >> >> Are there possibilities to avoid this? For example is possible have
> >> >> some
> >> >> kind of "isProcessingCompositeComponent" method and skip
> >> >> Pattern.matches() if false? We are in VDL.buildView here and no
> >> >> components are available yet, no use of methods like
> >> >> UIComponent.isCompositeComponent(UIComponent) is possible.
> >> >>
> >> >> Any ideas?
> >> >>
> >> >> Regards,
> >> >>
> >> >> Kočičák
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Jakob Korherr
> >>
> >> blog: http://www.jakobk.com
> >> twitter: http://twitter.com/jakobkorherr
> >> work: http://www.irian.at
> >
> >
>
>
>
> --
> Jakob Korherr
>
> blog: http://www.jakobk.com
> twitter: http://twitter.com/jakobkorherr
> work: http://www.irian.at
>
Re: [core] performance: TagAttributeImpl and composite component EL detection
Posted by Jakob Korherr <ja...@gmail.com>.
Hi Leo,
Hehe, yes, great idea!! I am wondering why we did not think of that in
the first place...
However one question - why are you using the approach with one integer
instead of three booleans? I know it's only a question about code
style, but it kinda seems odd.
Regards,
Jakob
2010/10/20 Leonardo Uribe <lu...@gmail.com>:
> Hi
>
> I have an idea: why don't evaluate that condition on construction time?
>
> In that case, EL will be scanned only once (when the Facelet or Abstract
> Syntax Tree (AST) is build) and
> not when the view is build, like is happening now.
>
> I have created an issue
>
> https://issues.apache.org/jira/browse/MYFACES-2951
>
> and committed the code in trunk.
>
> Suggestions are welcome.
>
> Leonardo Uribe
>
> 2010/10/20 Jakob Korherr <ja...@gmail.com>
>>
>> Hi Kočičák,
>>
>> There might be some ways to improve this, but we have to be very
>> careful in making changes to that area, because the whole composite
>> components + EL domain is not that easy.
>>
>> Actually the CompositeComponentELUtils.isCompositeComponentXYZ methods
>> were introduced by myself when fixing the #{cc} issues we encountered
>> in some MyFaces 2 alpha versions. Unfortunately I currently don't
>> really have time to think about improvements here, sorry. But I really
>> think that there is some room for improvements!
>>
>> Also I really like your idea of isProcessingCompositeComponent. This
>> might be a good way, because if this is false we can skip the #{cc}
>> check, because such expressions will certainly not occur outside of a
>> composite component. If you have some spare time, a patch would be
>> really great :) :) - otherwise please just open a JIRA issue for this
>> one so that we don't loose sight of it. Thanks!
>>
>> Regards,
>> Jakob
>>
>> 2010/10/20 Werner Punz <we...@gmail.com>:
>> > Just my 2c without looking into the code, but I assume speed
>> > improvements
>> > already can be gained by replacing the pattern matches, if possible with
>> > a
>> > direct ll comparison.
>> > Regexps often are heavier than simple parsing or string operations.
>> >
>> > Another thing might be that we add some caching mechanism on this level
>> > which caches per request if possible. But I have not looked into the
>> > code,
>> > so I am making wild assumptions here.
>> >
>> > I assume also that some speed still can be gained in this area by better
>> > utilization of the improved tree walking api jsf2 provides.
>> >
>> >
>> > Werner
>> >
>> >
>> > Am 20.10.10 15:54, schrieb Martin Koci:
>> >>
>> >> Hi,
>> >>
>> >>
>> >> a issue to consider in
>> >> org.apache.myfaces.view.facelets.tag.TagAttributeImpl:
>> >>
>> >>
>> >> Methods
>> >> TagAttributeImpl.getMethodExpression and
>> >> TagAttributeImpl.getValueExpression use
>> >> CompositeComponentELUtils.isCompositeComponentXYZ methods to detect if
>> >> current #{} contains cc expression. But consider following: if user
>> >> migrates from facelets 1.2 to 2.0, this new cc detection slows down
>> >> build view process. In one my test case VDL.buildView calls
>> >> CompositeComponentELUtils.isCompositeComponentXYZ approx 3000 times per
>> >> build view with no match. isCompositeComponentXYZ is not cheap method
>> >> because it uses Pattern.matches().
>> >>
>> >> Are there possibilities to avoid this? For example is possible have
>> >> some
>> >> kind of "isProcessingCompositeComponent" method and skip
>> >> Pattern.matches() if false? We are in VDL.buildView here and no
>> >> components are available yet, no use of methods like
>> >> UIComponent.isCompositeComponent(UIComponent) is possible.
>> >>
>> >> Any ideas?
>> >>
>> >> Regards,
>> >>
>> >> Kočičák
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>> >
>>
>>
>>
>> --
>> Jakob Korherr
>>
>> blog: http://www.jakobk.com
>> twitter: http://twitter.com/jakobkorherr
>> work: http://www.irian.at
>
>
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
Re: [core] performance: TagAttributeImpl and composite component
EL detection
Posted by Martin Koci <ma...@gmail.com>.
hehe, I was writing something similar: "in production stage
TagAttributeImpl is only created once and then facelets cache mechanism
keep this instance alive as part of Facelet memory structure. Thus if
user did request to all Facelet instances (all *xhtml) in JSF
application, it creates forest of Facelet instances, Facelet instances
are trees, those trees have nodes (Tag instances) with leafs =
TagAttribute instances. It this is true and if I remember well graph
theory long time ago at university, each TagAttribute instance is unique
and there exists only on path to it ->
why is ValueExpression evaluated new on every request?"
In short (I must go home now ...) : ValueExpression can differ in
expected type and facelets context. But can those values be really
diffirent for same TagAttribute instance? If they are always same can ve
cache ValueExpression instance forever?
Leonardo Uribe píše v St 20. 10. 2010 v 15:45 -0500:
> Hi
>
> I have an idea: why don't evaluate that condition on construction
> time?
>
> In that case, EL will be scanned only once (when the Facelet or
> Abstract Syntax Tree (AST) is build) and
> not when the view is build, like is happening now.
>
> I have created an issue
>
> https://issues.apache.org/jira/browse/MYFACES-2951
>
> and committed the code in trunk.
>
> Suggestions are welcome.
>
> Leonardo Uribe
>
> 2010/10/20 Jakob Korherr <ja...@gmail.com>
> Hi Kočičák,
>
> There might be some ways to improve this, but we have to be
> very
> careful in making changes to that area, because the whole
> composite
> components + EL domain is not that easy.
>
> Actually the CompositeComponentELUtils.isCompositeComponentXYZ
> methods
> were introduced by myself when fixing the #{cc} issues we
> encountered
> in some MyFaces 2 alpha versions. Unfortunately I currently
> don't
> really have time to think about improvements here, sorry. But
> I really
> think that there is some room for improvements!
>
> Also I really like your idea of
> isProcessingCompositeComponent. This
> might be a good way, because if this is false we can skip the
> #{cc}
> check, because such expressions will certainly not occur
> outside of a
> composite component. If you have some spare time, a patch
> would be
> really great :) :) - otherwise please just open a JIRA issue
> for this
> one so that we don't loose sight of it. Thanks!
>
> Regards,
> Jakob
>
> 2010/10/20 Werner Punz <we...@gmail.com>:
>
> > Just my 2c without looking into the code, but I assume speed
> improvements
> > already can be gained by replacing the pattern matches, if
> possible with a
> > direct ll comparison.
> > Regexps often are heavier than simple parsing or string
> operations.
> >
> > Another thing might be that we add some caching mechanism on
> this level
> > which caches per request if possible. But I have not looked
> into the code,
> > so I am making wild assumptions here.
> >
> > I assume also that some speed still can be gained in this
> area by better
> > utilization of the improved tree walking api jsf2 provides.
> >
> >
> > Werner
> >
> >
> > Am 20.10.10 15:54, schrieb Martin Koci:
> >>
> >> Hi,
> >>
> >>
> >> a issue to consider in
> >> org.apache.myfaces.view.facelets.tag.TagAttributeImpl:
> >>
> >>
> >> Methods
> >> TagAttributeImpl.getMethodExpression and
> >> TagAttributeImpl.getValueExpression use
> >> CompositeComponentELUtils.isCompositeComponentXYZ methods
> to detect if
> >> current #{} contains cc expression. But consider following:
> if user
> >> migrates from facelets 1.2 to 2.0, this new cc detection
> slows down
> >> build view process. In one my test case VDL.buildView calls
> >> CompositeComponentELUtils.isCompositeComponentXYZ approx
> 3000 times per
> >> build view with no match. isCompositeComponentXYZ is not
> cheap method
> >> because it uses Pattern.matches().
> >>
> >> Are there possibilities to avoid this? For example is
> possible have some
> >> kind of "isProcessingCompositeComponent" method and skip
> >> Pattern.matches() if false? We are in VDL.buildView here
> and no
> >> components are available yet, no use of methods like
> >> UIComponent.isCompositeComponent(UIComponent) is possible.
> >>
> >> Any ideas?
> >>
> >> Regards,
> >>
> >> Kočičák
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
>
>
>
>
> --
> Jakob Korherr
>
> blog: http://www.jakobk.com
> twitter: http://twitter.com/jakobkorherr
> work: http://www.irian.at
>
Re: [core] performance: TagAttributeImpl and composite component EL detection
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
I have an idea: why don't evaluate that condition on construction time?
In that case, EL will be scanned only once (when the Facelet or Abstract
Syntax Tree (AST) is build) and
not when the view is build, like is happening now.
I have created an issue
https://issues.apache.org/jira/browse/MYFACES-2951
and committed the code in trunk.
Suggestions are welcome.
Leonardo Uribe
2010/10/20 Jakob Korherr <ja...@gmail.com>
> Hi Kočičák,
>
> There might be some ways to improve this, but we have to be very
> careful in making changes to that area, because the whole composite
> components + EL domain is not that easy.
>
> Actually the CompositeComponentELUtils.isCompositeComponentXYZ methods
> were introduced by myself when fixing the #{cc} issues we encountered
> in some MyFaces 2 alpha versions. Unfortunately I currently don't
> really have time to think about improvements here, sorry. But I really
> think that there is some room for improvements!
>
> Also I really like your idea of isProcessingCompositeComponent. This
> might be a good way, because if this is false we can skip the #{cc}
> check, because such expressions will certainly not occur outside of a
> composite component. If you have some spare time, a patch would be
> really great :) :) - otherwise please just open a JIRA issue for this
> one so that we don't loose sight of it. Thanks!
>
> Regards,
> Jakob
>
> 2010/10/20 Werner Punz <we...@gmail.com>:
> > Just my 2c without looking into the code, but I assume speed improvements
> > already can be gained by replacing the pattern matches, if possible with
> a
> > direct ll comparison.
> > Regexps often are heavier than simple parsing or string operations.
> >
> > Another thing might be that we add some caching mechanism on this level
> > which caches per request if possible. But I have not looked into the
> code,
> > so I am making wild assumptions here.
> >
> > I assume also that some speed still can be gained in this area by better
> > utilization of the improved tree walking api jsf2 provides.
> >
> >
> > Werner
> >
> >
> > Am 20.10.10 15:54, schrieb Martin Koci:
> >>
> >> Hi,
> >>
> >>
> >> a issue to consider in
> >> org.apache.myfaces.view.facelets.tag.TagAttributeImpl:
> >>
> >>
> >> Methods
> >> TagAttributeImpl.getMethodExpression and
> >> TagAttributeImpl.getValueExpression use
> >> CompositeComponentELUtils.isCompositeComponentXYZ methods to detect if
> >> current #{} contains cc expression. But consider following: if user
> >> migrates from facelets 1.2 to 2.0, this new cc detection slows down
> >> build view process. In one my test case VDL.buildView calls
> >> CompositeComponentELUtils.isCompositeComponentXYZ approx 3000 times per
> >> build view with no match. isCompositeComponentXYZ is not cheap method
> >> because it uses Pattern.matches().
> >>
> >> Are there possibilities to avoid this? For example is possible have some
> >> kind of "isProcessingCompositeComponent" method and skip
> >> Pattern.matches() if false? We are in VDL.buildView here and no
> >> components are available yet, no use of methods like
> >> UIComponent.isCompositeComponent(UIComponent) is possible.
> >>
> >> Any ideas?
> >>
> >> Regards,
> >>
> >> Kočičák
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
>
>
>
> --
> Jakob Korherr
>
> blog: http://www.jakobk.com
> twitter: http://twitter.com/jakobkorherr
> work: http://www.irian.at
>
Re: [core] performance: TagAttributeImpl and composite component EL detection
Posted by Jakob Korherr <ja...@gmail.com>.
Hi Kočičák,
There might be some ways to improve this, but we have to be very
careful in making changes to that area, because the whole composite
components + EL domain is not that easy.
Actually the CompositeComponentELUtils.isCompositeComponentXYZ methods
were introduced by myself when fixing the #{cc} issues we encountered
in some MyFaces 2 alpha versions. Unfortunately I currently don't
really have time to think about improvements here, sorry. But I really
think that there is some room for improvements!
Also I really like your idea of isProcessingCompositeComponent. This
might be a good way, because if this is false we can skip the #{cc}
check, because such expressions will certainly not occur outside of a
composite component. If you have some spare time, a patch would be
really great :) :) - otherwise please just open a JIRA issue for this
one so that we don't loose sight of it. Thanks!
Regards,
Jakob
2010/10/20 Werner Punz <we...@gmail.com>:
> Just my 2c without looking into the code, but I assume speed improvements
> already can be gained by replacing the pattern matches, if possible with a
> direct ll comparison.
> Regexps often are heavier than simple parsing or string operations.
>
> Another thing might be that we add some caching mechanism on this level
> which caches per request if possible. But I have not looked into the code,
> so I am making wild assumptions here.
>
> I assume also that some speed still can be gained in this area by better
> utilization of the improved tree walking api jsf2 provides.
>
>
> Werner
>
>
> Am 20.10.10 15:54, schrieb Martin Koci:
>>
>> Hi,
>>
>>
>> a issue to consider in
>> org.apache.myfaces.view.facelets.tag.TagAttributeImpl:
>>
>>
>> Methods
>> TagAttributeImpl.getMethodExpression and
>> TagAttributeImpl.getValueExpression use
>> CompositeComponentELUtils.isCompositeComponentXYZ methods to detect if
>> current #{} contains cc expression. But consider following: if user
>> migrates from facelets 1.2 to 2.0, this new cc detection slows down
>> build view process. In one my test case VDL.buildView calls
>> CompositeComponentELUtils.isCompositeComponentXYZ approx 3000 times per
>> build view with no match. isCompositeComponentXYZ is not cheap method
>> because it uses Pattern.matches().
>>
>> Are there possibilities to avoid this? For example is possible have some
>> kind of "isProcessingCompositeComponent" method and skip
>> Pattern.matches() if false? We are in VDL.buildView here and no
>> components are available yet, no use of methods like
>> UIComponent.isCompositeComponent(UIComponent) is possible.
>>
>> Any ideas?
>>
>> Regards,
>>
>> Kočičák
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
Re: [core] performance: TagAttributeImpl and composite component
EL detection
Posted by Werner Punz <we...@gmail.com>.
Just my 2c without looking into the code, but I assume speed
improvements already can be gained by replacing the pattern matches, if
possible with a direct ll comparison.
Regexps often are heavier than simple parsing or string operations.
Another thing might be that we add some caching mechanism on this level
which caches per request if possible. But I have not looked into the
code, so I am making wild assumptions here.
I assume also that some speed still can be gained in this area by better
utilization of the improved tree walking api jsf2 provides.
Werner
Am 20.10.10 15:54, schrieb Martin Koci:
> Hi,
>
>
> a issue to consider in
> org.apache.myfaces.view.facelets.tag.TagAttributeImpl:
>
>
> Methods
> TagAttributeImpl.getMethodExpression and
> TagAttributeImpl.getValueExpression use
> CompositeComponentELUtils.isCompositeComponentXYZ methods to detect if
> current #{} contains cc expression. But consider following: if user
> migrates from facelets 1.2 to 2.0, this new cc detection slows down
> build view process. In one my test case VDL.buildView calls
> CompositeComponentELUtils.isCompositeComponentXYZ approx 3000 times per
> build view with no match. isCompositeComponentXYZ is not cheap method
> because it uses Pattern.matches().
>
> Are there possibilities to avoid this? For example is possible have some
> kind of "isProcessingCompositeComponent" method and skip
> Pattern.matches() if false? We are in VDL.buildView here and no
> components are available yet, no use of methods like
> UIComponent.isCompositeComponent(UIComponent) is possible.
>
> Any ideas?
>
> Regards,
>
> Kočičák
>
>
>
>
>
>
>
>
>
>