[jira] Commented: (TRINIDAD-1668) Speed up UIXComponent.getId()

["Blake Sullivan (JIRA)" <de...@myfaces.apache.org>]

    [ https://issues.apache.org/jira/browse/TRINIDAD-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829388#action_12829388 ] 

Blake Sullivan commented on TRINIDAD-1668:
------------------------------------------

There is a difference in behavior with the code--if the set of available keys is checked, the ID won't be in the set.  I'll check in a fix

> Speed up UIXComponent.getId()
> -----------------------------
>
>                 Key: TRINIDAD-1668
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-1668
>             Project: MyFaces Trinidad
>          Issue Type: Improvement
>    Affects Versions:  1.2.12-core
>         Environment: All
>            Reporter: Blake Sullivan
>            Assignee: Blake Sullivan
>             Fix For: 1.2.13-core 
>
>         Attachments: JIRA_1668_1_2_12_2.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> 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
> 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
> 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

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.