Re: [TRINIDAD][API]TRINIDAD-1668 Speed up UIXComponent.getId()

Blake Sullivan Tue, 05 Jan 2010 11:51:51 -0800

The reason is that we need to support AttributeMap/component accessorequivalence--get/set of the id attribute through the Map is supposed towork correctly. The ValueExpression only exists to make this work.


-- Blake Sullivan


Simon Lessard said the following On 1/5/2010 10:57 AM PT:

Hi,

Why not simply NOT support a PropertyKey for the id attribute? I know it
isn't consistent with the other properties, but id is a very special case
not supporting EL anyway. In all the project I ever did, I never used
FacesBean.getProperty(ID_PROPERTY_KEY). The only drawback I would see is if
the component's id actually need to be read in a property getter method in a
renderer which receive only the FacesBean instance and not the component
itself. That would be much faster than a custom ValueExpression and the
memory footprint would also be better.

Regards,

~ Simon

On Tue, Jan 5, 2010 at 1:49 PM, Matthias Wessendorf <[email protected]>wrote:

On Thu, Dec 31, 2009 at 11:12 PM, Blake Sullivan
<[email protected]> wrote:

UIComponent.getId() is by far the most requested component attribute.

 There

are a number of reasons for this:
1) The JSF RI has an issue in the JSP-JSF integration which causes

getId()

to be called n^2 times where n is the number of children a component has

I guess this is true for MyFaces as well, right?

2) getClientId() calls getId()
3) FindComponent calls getId()
4) The tree visiting code trades off calls to getClientId() for calls to
getId()

FacesBean optimizes attribute Map access at the expense of access

directly

through the component.  The the extent that Renderers are Components are
accessing the attributes through the attribute Map, this is fine, however
even the Renderers access attributes common to all UIComponents such as

id()

through the component directly.  Considering the huge number of times

that

the the id is accessed (for some renders, this was 8% of the rendering
time), it makes sense to optimize this path.

The proposal is to:
1) Store the id an an instance variable on the UIXComponent
2) Add a new capability flag to PropertyKey indicating that the property

is

actually stored elsewhere using a ValueExpression will be stored as the
property's value in the PropertyMap.  For access through the FacesBean,

the

ValueExpression will be evaluated to get/set the actual value
3) For state saving the ValueExpression is used to retrieve the actual

value

and for state restoration the ValueExpression (which has been

rebootstrapped

by the UIXComponent) is used to write the value back
4) Instead of setting the id attribute in the FacesBean, UIXComponent

stores

it locally and sets an ValueExpression implementation into the FacesBean
that retrieves the value from the UIXComponent

+1 on api/patch

API Changes:

PropertyKey:

add

 /**
 * Capability indicating that values for this property should be
 * be stored and retrieved through a ValueExpression rather than on the
 * FacesBean itself
 */
 static public final int CAP_VALUE_EXPRESSION_IMPLEMENTATION = 16;

 /**
 * Returns <code>true</code> if property values for this key are set and

get

 * using a ValueExpression rather than storing the value in the

FacesBean.

 * @return <code>true</code> if properties values for this key are

retrieved

 * with a ValueExpression.
 */
 public boolean usesValueExpressionAsImplementation()

After this change id retrieval doesn't make the 1% YourKit profiler hot

spot

cut off


--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Re: [TRINIDAD][API]TRINIDAD-1668 Speed up UIXComponent.getId()

Reply via email to