myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Bohmann <bernd.bohm...@atanion.com>
Subject Re: [core] performance: performance hints
Date Fri, 22 Jul 2011 21:17:38 GMT
Hello Leonardo,

can we backport this code to 1.2.x?

Regards

Bernd

On Fri, Jul 22, 2011 at 11:10 PM, Leonardo Uribe <lu4242@gmail.com> wrote:
> Hi
>
> Just for your informatino, I did some really big improvements over the
> algorithm, making unnecessary add this hint. See:
>
> https://issues.apache.org/jira/browse/MYFACES-3236
>
> for details. This was commited on 2.0.x and 2.1.x branch. It could be
> good if someone can do some performance tests over this one.
>
> regards,
>
> Leonardo Uribe
>
> 2011/4/28 Leonardo Uribe <lu4242@gmail.com>:
>> Hi
>>
>> Ok, I'll do a resume about the discussion and provide some opinions
>>  about that.
>>
>> LU >>>>That could be better, and it has sense to put in tomahawk,
>> LU >>>> because after all that is the right location for extend
>> LU >>>> default jsf components.
>>
>> MK >> Yes, this is one point of view and I agree with that "custom behaviour
>> MK >> belongs into custom component". I did exactly the same for my
>> component.
>>
>> MK >> But there are other topics to consider:
>>
>> MK >> 0) simple presence of performance hints in core does not break the
>> MK >> compatibility : the *usage* of that hint can break the compatibility
-
>> MK >>so as usual, user must know what that parameter means and what  it can
>> MK >> cause.
>>
>> Yes, the important thing to note is this could not be the default behavior.
>>
>> MK >> 1) I think JSF implementation can break the specified functionality:
>> MK >> myfaces did it already with elResolvers sorting for example. But the
>> MK >> default must be always false for 100% compatibility with JSF
>> MK >> specification.
>>
>> Yes, note the default algorithm provide the elResolvers in the expected
>> order as
>> the spec says.
>>
>> MK >> 2) The hint technique is very common : another example from Java EE is
>> MK >> world JPA Query.setHint
>>
>> Good example.
>>
>> MK >> 3) Hints are a simple way to realize something "this should be in
>> core"
>> MK >> but because of slow specification release cycle, you must wait a year
>> or
>> MK >> two to get it officially specified in public API.
>>
>> Agreed
>>
>> MK >> 4) Ease of usage: for example, if you have only one readonly table in
>> MK >> whole project, creation of custom component for that purpose is an
>> MK >> overkill: simple <f:attribute name="oam.readOnly" value="true" />
is
>> MK >> much easier.
>>
>> Good idea. I like the proposal of use an attribute like "oam.readOnly",
>> because
>> users can see quickly this attribute is MyFaces specific. But note an
>> interesting
>> point, in facelets mode, use f:attribute is not necessary because there
>> exists
>> a MethodRule called org.apache.myfaces.view.facelets.tag.jsf.ComponentRule
>> that is added by default to all component tags and automatically wire all
>> attributes
>> to the attribute map. So this could be valid too:
>>
>> <h:dataTable oam.readOnly="true" ... >
>>
>> Note internally, the value assigned to this property will be a String, not a
>> boolean,
>> because f:attribute or ComponentRule can't do type conversion in this case.
>>
>> MK >> 5) Internet is full of "JSF is slow". Although I know that is
>> completely
>> MK >> untrue, "hinting the core" for more performance is a easy way which
>> MK >> allows users to express all they need without additional dependencies.
>>
>> Agreed.
>>
>> MK >> So, do you think we really can't put this feature in core? I mean the
>> MK >> "hints feature" generally, not readonly UIData - that was only an
>> MK >> example.
>>
>> Based on the latest information I think it is ok to add it, as long as we
>> use a
>> distinctive name (like oam.readOnly) to indicate the attribute is myfaces
>> specific.
>> Note this new attribute should be included on MyFaces generated facelets tld
>> javadoc.
>>
>> AS >> Blake's Axiom of Boolean Properties:  You will regret making your
>> AS >> property a boolean.
>>
>> :-) Really it is not a big deal, but good point.
>>
>> Really my opinion is it is possible for UIData to perform better without
>> introduce
>> this hint, and we should aim for that first. It could be good if UIData
>> knows that
>> there are no EditableValueHolder instances on the component tree, just skip
>> state saving automatically (in fact that code will only be executed just
>> once per
>> request).
>>
>> AS >> Though now that UIData is stuck with a boolean type for this property,
>> AS >> we don't have a simple way to support #3 (for UIData) that doesn't
>> AS >> involve adding yet another attribute.
>>
>> AS >> In any case, I think it is fine to support this optimization one way
>> AS >> or another (eg. along the lines discussed above).
>>
>> AS >> Of course, the magical ideal solution would be to come up with some
>> AS >> clever way to automatically pick the best behavior.  Or, failing that,
>> AS >> it might be good to warn developers when they specify potentially
>> AS >> conflicting values (such as disabling state saving for tables that
>> AS >> stamp EditableValueHolders.)
>>
>> I was thinking on put some code in JSF 2.1 for UData.markInitialState, that
>> check if there is EditableValueHolder instances on the row, and if no
>> instance is
>> found, make UIData skip automatically state saving code.
>>
>> Suggestions are welcome
>>
>> regards,
>>
>> Leonardo Uribe
>>
>> 2011/4/27 Jakob Korherr <jakob.korherr@gmail.com>
>>>
>>> Hi,
>>>
>>> I totally agree with Martin here, in all 6 points ;)
>>>
>>> The standard behavior of MyFaces core must always match with the spec
>>> (--> TCK). However, we can provide as much customisation as we want,
>>> but you always have to turn it on manually (e.g. via web.xml).
>>>
>>> Regards,
>>> Jakob
>>>
>>> 2011/4/26 Mark Struberg <struberg@yahoo.de>:
>>> > heh, that reminds me of the quardrary logic of an old colleague:
>>> >
>>> > ja/nein/weißnicht/habangst
>>> >
>>> > (roughly translates to : yes/no/ihavenoidea/angst)
>>> >
>>> > :)
>>> >
>>> > LieGrue,
>>> > strub
>>> >
>>> > --- On Tue, 4/26/11, Andy Schwartz <andy.g.schwartz@gmail.com> wrote:
>>> >
>>> >> From: Andy Schwartz <andy.g.schwartz@gmail.com>
>>> >> Subject: Re: [core] performance: performance hints
>>> >> To: "MyFaces Development" <dev@myfaces.apache.org>
>>> >> Date: Tuesday, April 26, 2011, 5:54 PM
>>> >> I think it is time to propose a new
>>> >> axiom relating to boolean
>>> >> properties.  I would name it after Blake, who first
>>> >> called this truth
>>> >> to my attention:
>>> >>
>>> >> Blake's Axiom of Boolean Properties:  You will regret
>>> >> making your
>>> >> property a boolean.
>>> >>
>>> >> :-)
>>> >>
>>> >> In this particular case, I am thinking about the UIData
>>> >> "rowStatePreserved" boolean property that we added in JSF
>>> >> 2.1.  This
>>> >> currently has two values:
>>> >>
>>> >> 1.  true: UIData performs state saving (ideally
>>> >> partial state saving)
>>> >> to save away row-specific properties.
>>> >> 2.  false: UIData uses the old hacky mechanism for
>>> >> saving row-specific
>>> >> state (special casing EditableValueHolders and what not).
>>> >>
>>> >> In retrospect, it sure would have been nice to allow for a
>>> >> third value:
>>> >>
>>> >> 3.  none:  Don't make any attempt at state
>>> >> saving.
>>> >>
>>> >> Though now that UIData is stuck with a boolean type for
>>> >> this property,
>>> >> we don't have a simple way to support #3 (for UIData) that
>>> >> doesn't
>>> >> involve adding yet another attribute.
>>> >>
>>> >> In any case, I think it is fine to support this
>>> >> optimization one way
>>> >> or another (eg. along the lines discussed above).
>>> >>
>>> >> Of course, the magical ideal solution would be to come up
>>> >> with some
>>> >> clever way to automatically pick the best behavior.
>>> >> Or, failing that,
>>> >> it might be good to warn developers when they specify
>>> >> potentially
>>> >> conflicting values (such as disabling state saving for
>>> >> tables that
>>> >> stamp EditableValueHolders.)
>>> >>
>>> >> Andy
>>> >>
>>> >
>>>
>>>
>>>
>>> --
>>> Jakob Korherr
>>>
>>> blog: http://www.jakobk.com
>>> twitter: http://twitter.com/jakobkorherr
>>> work: http://www.irian.at
>>
>>
>

Mime
View raw message