ICEfaces
  1. ICEfaces
  2. ICE-11516

Performance Issues before the 4.3 P03 Release

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: None
          • Fix Version/s: EE-4.3.0.GA_P03
          • Component/s: Framework
          • Labels:
            None
          • Environment:
            Any

            Description

            There's a slight but noticeable performance issue with ajax requests in the 4.3 trunk after the 4.3 P02 release. Some ajax requests are taking about 600 ms on average (plus/minus 200 ms) with the head revision, while in the P02 release they take only about 150 ms on average (plus/minus 50 ms).

            An easy way to appreciate this performance issue is to deploy the showcase app locally, using the head revision, and to open the online showcase on another tab, and compare them side by side (http://icefaces-showcase.icesoft.org/showcase.jsf). A couple of demos where the increased delays can be easily appreciated are the ace:autoCompleteEntry > Select Items demo, after typing or selecting values, and the ace:selectMenu demos, after selecting values. However, the slower performance can be felt in general with any ajax request. Things feel less "immediate", in general.

            Commits related to ICE-11502 seem to be the cause of this issue. Revision 53249 is the last revision that doesn't show this performance issue. After that, revisions 53267 through 53281 don't compile, because of a missing method. Then, at revision 53300 that method was re-introduced, and the performance issue can be seen there. Most of the commits in between are related to ICE-11502.

            This issue is present whether or not the 'javax.faces.CLIENT_WINDOW_MODE' context parameter is declared or not (and set to 'url') in web.xml.

            This issue is not present on the EE 3.3 maintenance branch (with or without the 'javax.faces.CLIENT_WINDOW_MODE' context parameter).

              Activity

              Ascending order - Click to sort in descending order
              Arturo Zambrano created issue -
              Arturo Zambrano made changes -
              Field Original Value New Value
              Fix Version/s EE-4.3.0.GA_P03 [ 13570 ]
              Arturo Zambrano made changes -
              Summary Performance Issues Before 4.3 P03 Release Performance Issues Before the 4.3 P03 Release
              Arturo Zambrano made changes -
              Summary Performance Issues Before the 4.3 P03 Release Performance Issues before the 4.3 P03 Release
              Mircea Toma made changes -
              Assignee Mircea Toma [ mircea.toma ]
              Repository Revision Date User Message
              ICEsoft Public SVN Repository #53378 Mon Jul 12 16:37:11 MDT 2021 mircea.toma ICE-11516 Override FacesContext.getELContext to save ICEfacesContext instance whenever invoked to avoid re-instantiating ICEfacesContext every time WindowELResolver.getValue is invoked.
              Files Changed
              Commit graph MODIFY /icefaces4/trunk/icefaces/core/src/main/java/org/icefaces/impl/context/ICEfacesContext.java
              Commit graph MODIFY /icefaces4/trunk/icefaces/core/src/main/java/org/icefaces/impl/application/WindowELResolver.java
              Hide
              Permalink
              Mircea Toma added a comment - - edited

              The performance issue was introduced by commit #53300 when WindowELResolver was modified to invoke WindowScopeManager.lookupWindowScope on a freshly instantiated ICEfacesContext decorator for FacesContextImpl.
              ICEfacesContext extends FacesContext to modify some of its basic behaviour and thus help implementing URL based window tracking. Unfortunately every time ICEfacesContext is instantiated FacesContext's no-parameter constructor is also invoked, which in turn tries to programmatically get the stack trace, a processing intensive task.

              The applied fix avoids to decorate FacesContext (with new ICEfacesContext instances) in WindowELResolver, instead ICEfacesContext which is normally created by ICEFacesContextFactory at the beginning of the JSF lifecycle will save itself into ELContext to make itself available to WindowELResolver.

              Show
              Mircea Toma added a comment - - edited The performance issue was introduced by commit #53300 when WindowELResolver was modified to invoke WindowScopeManager.lookupWindowScope on a freshly instantiated ICEfacesContext decorator for FacesContextImpl . ICEfacesContext extends FacesContext to modify some of its basic behaviour and thus help implementing URL based window tracking. Unfortunately every time ICEfacesContext is instantiated FacesContext 's no-parameter constructor is also invoked, which in turn tries to programmatically get the stack trace, a processing intensive task. The applied fix avoids to decorate FacesContext (with new ICEfacesContext instances) in WindowELResolver , instead ICEfacesContext which is normally created by ICEFacesContextFactory at the beginning of the JSF lifecycle will save itself into ELContext to make itself available to WindowELResolver .
              Mircea Toma made changes -
              Status Open [ 1 ] Resolved [ 5 ]
              Resolution Fixed [ 1 ]
              Ken Fyten made changes -
              Status Resolved [ 5 ] Closed [ 6 ]

                People

                • Assignee:
                  Mircea Toma
                  Reporter:
                  Arturo Zambrano
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  2 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: