[
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.
