Details
-
Type:
Bug
-
Status: Closed
-
Priority:
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 toICE-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).
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
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
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
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.