Bug fixed revision #10058

The DOM updates have been optimized by assigning IDs to all TreeNode DIVs.
Prior to this change only the Elements contained in the DIVs were assigned IDs.

Philip,

Have noticed any issues around tree performance ?

I am able to run large trees > 500 nodes in both browsers.

I see performance issues and out of memory error when I put selectInputDate
components inside large trees.[ javax.servlet.ServletException:
java.lang.OutOfMemoryError. ]

I'm going to open an Iraptor specifically for the selectInputDate in a Tree.

A new Iraptor has been filed for the Tree with selectInputDate. See Iraptor #976.

Some performance results from Philip for the record.
-------------------------------------
I'm testing out the tree performance now, and it seems to be significantly
improved. I can collapse and expand branches with about 100 nodes comprised of
inputText's and radios in < 10 seconds. The perf is ok up until you get above
1000 nodes for the whole tree. After that I get the long-script problem again.
-------------------------------------

Re-opening this bug based on unsatisfactory pre-release testing results from
DaimlerChrysler.

More test results:
Scenario 1:
100 nodes directly under root node.
Both browsers perform well.

Scenario 2:
200 nodes directly under root node.
Firefox performs well and IE performance is slightly slower.

Scenario 3:
300 nodes directly under root node.
Firefox is slightly slower and IE performance is poor.

Scenario 4:
400 nodes directly under root node.
Firefox is slower and IE performance is bad.

Another fix in commit #11852.

See explanation at:

• http://mir.aculo.us/articles/2005/08/28/internet-explorer-and-ajax-image-caching-woes
• http://www.bazon.net/mishoo/articles.epl?art_id=958
• http://support.microsoft.com/default.aspx?scid=kb;en-us;319546

We should re-evaluate the tree performance for the 1.6 release.

http://www.icefaces.org/JForum/posts/list/5156.page#23028

This is very likely due to IE JavaScript specifics. Maybe we can adjust the implementation just for IE?

Is this due to form serialization or to memory leak prevention code?

(I recall that serializing a form in IE can be done in a fraction of a second even with thousands of nodes.)

Further analysis indicates nothing obvious that can be done to further improve the existing tree component under IE. Modifying the components to not require a form may offer the best path forward in terms of reducing the amount of content that must be introduced or removed with each tree node expansion or collapse. The scope of this enhancement makes it an ICEfaces 2.0 concern, however.

The performance problems may be due to our memory leak prevention strategy on IE rather than form serialization, so there may be options for changing how object references are removed (for instance in small batches in a series of setTimeouts).

Further investigation has shown that simply iterating over form elements in Internet Explorer is very inefficient. This is likely due to the architecture of IE, with the DOM and Script memory spaces being entirely separate (almost like the JNI separation between Java and native code). When a DOM node in IE is referenced, it may cause the creation of an associated JavaScript object, and this process is very expensive.

However, there appear to be ways to cache needed objects within the JavaScript memory space. As the attached example shows, a large form can be dynamically created and processed efficiently provided the dynamic creation of the form employs caching (appendChild() is called with many nodes) and the iteration employs caching (a cache of the form nodes as an array).

Note that the ultimate problem is to efficiently exchange the results of user interaction with the server, and other strategies are possible (such as purely event-based interaction). Working with forms has the advantage of renderer simplicity, third-party component compatibility and smooth degradation under non-JavaScript scenarios.

Assigning to Mircea. Note that this is a subtle bug and may require a mixture of strategies to resolve.

The attached files illustrate updating a document via innerHTML. This is rapid in Internet Explorer and IE is able to rapidly iterate through a form updated in this fashion. It appears, therefore, that ICEfaces is currently using DOM APIs to update the page (rather than innerHTML) and this is likely the cause of the performance problems on IE.

It appears that IE can quickly return innerHTML and that innerHTML returns the current state of the form (unlike for Safari or Firefox).

Hence, innerHTML could be used on IE for efficient form serialization.

This version of the loop:

var formElements = form.elements;
var length = formElements.length;
for(i=0; i<length; i++)

is many orders of magnitude faster than this version:

for(i=0; i<form.elements.length; i++)

Experimentation with this "caching" strategy had been tried before, but possibly not with the "var" keyword.

Use of the "var" keyword may not be essential, but further testing indicates that both the array and the index must be kept as local variables.

More insanely convoluted performance tips here:

http://blogs.msdn.com/ie/archive/2006/08/28/728654.aspx

Fix 'for' loops to use precalculated length.
Serialize view numbers only once per submit.
Fix form element retrieval for Safari.
Remove check for duplicate parameters (check rendered useless due to previously mentioned fix).

Significant improvement to complex page performance is an important bug fix for several customers, it's worth highlighting in the 1.7DR#1 release notes.

Philip, do you have a test case for large numbers of row selectors? We should verify that this fix helps in that case as well.

Applied fix to 1.6 branch.

Hi,
Icefaces tree 2.0 is still very slow in Internet explorer, is there any workaround?

Hi,
Icefaces tree 2.0 is still very slow in Internet explorer, is there any workaround?

Are the tree nodes themselves complex? We might be able to help by looking at the specific application.

I have around 50 nodes directly under root node which works fast in mozilla but really slow in IE. My TreeNode extends IceUserObject and is composed of a few members.
It seems the problem is related to DOM management in IE, even because the same component works fine with Mozilla.