Details
-
Type: Improvement
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: EE-3.3.0.GA, 4.0.BETA, 4.0
-
Labels:None
-
Environment:ICEfaces framework, bridge
-
Assignee Priority:P2
-
Affects:Documentation (User Guide, Ref. Guide, etc.)
Description
Currently (3.2), when the bridge applies DOM updates it then scans all components looking for components with 'onElementUpdate' callbacks defined that are affected by the updated DOM region. This process occurs in JavaScript on the browser, and can be very expensive/slow particularly on IE7/8 browsers. This performance issue is preventing wide-scale adoption of the the onElementUpdate callback to improve JS memory cleanup in the ACE components.
An improved implementation may be to compile a list of the components affected by a particular DOM update on the server, such that the bridge could then simply call each one's onElementUpdate callback in sequence and avoid the expensive searching through the component list on the browser. Presumably the callback list would be sent to the bridge as part of each DOM update message.
An improved implementation may be to compile a list of the components affected by a particular DOM update on the server, such that the bridge could then simply call each one's onElementUpdate callback in sequence and avoid the expensive searching through the component list on the browser. Presumably the callback list would be sent to the bridge as part of each DOM update message.
This appears to directly defeat a variety of optimizations:
client-side, it defeats the use of innerHTML, server-side it defeats
DOM diff short circuits.
If the number of listeners is "small", then for each listener we
could store the DOM node before the update and check its DOM status
(walk up to root) after the update is applied. If it is not in the DOM, the listener would be called. (The question is whether this works on IE; if there are difficulties, perhaps checking the root node for identity against the current root node would work.)
Essentially we're trying to do this:
https://developer.mozilla.org/en-US/docs/DOM/Mutation_events
1.5x - 7x slowdown in DOM operations
A server-side implementation of this would require substantial interaction with the "old" DOM, which is likely to be inefficient (this requirement was not realized when the server-side technique was originally proposed).
The main point is that this listener technique should be avoided as much as possible.