[jira] Resolved: (TRINIDAD-1899) SessionChangeManager performance and behavior improvements

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

     [ https://issues.apache.org/jira/browse/TRINIDAD-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Blake Sullivan resolved TRINIDAD-1899.
--------------------------------------

    Resolution: Fixed

Resolved in revision 992031 on main
Resolved in revision 992030 on 1.2.x


> SessionChangeManager performance and behavior improvements
> ----------------------------------------------------------
>
>                 Key: TRINIDAD-1899
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-1899
>             Project: MyFaces Trinidad
>          Issue Type: Improvement
>    Affects Versions: 1.2.14-core , 2.0.0.3-core
>            Reporter: Blake Sullivan
>            Assignee: Blake Sullivan
>         Attachments: trin_1899_1_2_x.diff, trin_1899_main.diff
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Currently the SessionChangeManager when working with JSPs maintains a single list of changes to be applied and applies them in order.  While the list does support collapsing attribute changes even across component moves, this approach has some performance limitations in and of itself and decreases our ability to make other performance improvements:
> 1) Because some changes affect multiple components, we wait to the end of the document tag to apply the changes (so that all components exist).  Unfortunately this means that when the tags are executing, they don't actually have any values that were modified by a change available to them.  This prevents us from applying optimizations where we don't even execute the tags that are subtrees that won't be visited by the lifecycle (for example undisclosed tabs).  
> 2) Because the changes are not applied at the time of tag execution, we need to do a separate findComponent() for each change that we want to apply.  This can get expensive for large numbers of changes.
> The solution is to group changes into
> 1) Changes that apply to a single component
> a) Collapsible single changes
> 2) Cross component changes
> a) Cross component changes that can change the identity of a component
> 1) Changes that are applied to a single component are saved under the component's original scoped identifier.  The collapsible changes are collapsed.
> 2) Cross component changes are maintained in a single page wide list
> 3) Cross component changes that change the identify of a component update a mapping from the new (current scoped identifier) for the component to the original scoped identifier so that as new changes are applied, they are applied to the correct entry in 1)
> 4) For efficiency, the serialized form of the changes is a single list of changes with all collapsible entries collapsed, even across changes that change the identity.  The rename maps and a single component changes can be rebuilt on demand from this list.
> The upshot of these changes are that:
> 1) We can apply all of the single component changes to a component at tag execution time, even if that component had a change that moved it.  This opens up optimizations where we don't execute child tags
> 2) Since all collapsible changes, like attribute changes are collapsed, we have fewer changes to apply
> 3) Only the rare, cross-component changes need to be applied using separate findComponent calls
> To apply the changes at tag execution time, we need a new api on ChangeManager:
>   /**
>    * Apply non-cross-component changes to a component in its original location.  This is typically
>    * only called by tags that need to ensure that a newly created component instance is
>    * as up-to-date as possible.
>    * @param context
>    * @param component Component to apply the simple changes to
>    */
>   public void applySimpleComponentChanges(FacesContext context, UIComponent component)

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