[seam-issues] [JBoss JIRA] (JBSEAM-5075) Improve Seam2.3 performance

[Marek Novotny (JIRA)]

     [ https://issues.jboss.org/browse/JBSEAM-5075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Novotny updated JBSEAM-5075:
----------------------------------

    Comment: was deleted

(was: Graph attached. I'll continue on investigation of mentioned issues. )

    
> Improve Seam2.3 performance
> ---------------------------
>
>                 Key: JBSEAM-5075
>                 URL: https://issues.jboss.org/browse/JBSEAM-5075
>             Project: Seam 2
>          Issue Type: Enhancement
>          Components: Performance and Scalability
>    Affects Versions: 2.3.0.Final
>         Environment: AS 7.1.3.Final (EAP 6.0.1)
>            Reporter: Tomas Remes
>
> I've run several performance (especially load) tests comparing Seam2.3 to Seam2.2. I am using modified numberguess example running on AS 7.1.3.Final (EAP 6.0.1). Major difference between those two versions is that Seam2.2 uses JSF-1.2 (Mojarra-1.2_15-b01-FCS) and Seam2.3 uses JSF-2.1 (Mojarra 2.1.13-jbossorg-1). The tests shows significantly worse results of Seam2.3 release especially in response time values. Literally Seam2.3 reaches only about 50% of response time values in comparison to Seam2.2 version. In other words that is two times worse. Profiling shows following points, which can be IMHO improved:
> 1) Implementation of SeamVieHandler's restoreView method. This method currently allocates approximately 10x times more memory than related one from Seam2.2 (it uses FaceletViewHandler.restoreView). Removing (returning to Seam2.2 implementation) following lines from this method can bring performance improvement (I've already tried that): 
> {noformat}
>       UIViewRoot viewRoot =viewHandler.restoreView(ctx, viewId);
>       if (viewRoot != null)
>       {
>          viewRoot.setViewId(viewHandler.deriveViewId(ctx,viewId));
>       }
> {noformat}
> 2) Implementation of Contexts.isPageContextActive method. This also shows some regression when comparing memory allocation to related methods - ConversationPropagation.restoreConversationId and Manager.restoreConversation. IMHO this can be reimplemented somehow too.
> 3) Implementation of StatusMessages.instance() method. This also brings small regression in memory allocation. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira