Dijit Tree, How To Improve Performance For A Large Tree With 500 Child Nodes Under Root

Each tree node contains other inner widgets, so it takes long time to render the whole 500 items especially in IE. It may take 10-20 seconds to render the tree in IE. I was wonderi

Solution 1:

If you don't have that many root nodes, you could use a lazy loading mechanism, see for example this article at sitepen

be warned though, it works well with dojo 1.4 - 1.5.1, in dojo 1.6.1 there are some strange issues with the JsonRestStore.

See this question at stackoverflow

edit to match the clarification

I don't think it's possible for the tree to only build the nodes in the view area. At least this is not possible with the standard dijit.tree.

In one of our applications we inserted structure nodes as a workaround, i.e.

root
---[1..30] - structure node 
  ---item1
  ---item2
  ...
---[31..60] - structure node
   ---item31
   ---item32
   ...
...

on the other hand, it sounds like the tree grid is a close match to what you want, maybe it could work with a bit of styling

Solution 2:

This may be a late response, but a project I'm working on had the same problem, and the application has to run in IE7, so the performance was definitely not good. The core problem is when you have many nodes at one level, and we were dealing with hundreds if not over a thousand, causing the dreaded script-running dialog to popup.

We recently replaced the use of dijit.Tree with our own tree implementation, finding the extra abstraction of the backing store unnecessary since the server already was the data abstraction layer. Hence, we have the server generate an HTML fragment, using divs and spans to represent the structure of the tree and custom attributes to associate data for each node. CSS is used to format the data visually.

This approach leverages the intrinsic capability of the browser to process HTML. A few connections to mouse and keyboard events allows us to get full tree-based functionality (including tooltips for nodes) in an efficient manner. Here's a simplified example of the type of HTML structure our server generates:

<divclass="treeFolder"><spanclass="treeFolderInd">+</span><spanclass="treeFolderLabel">Folder label</span><divclass="treeFolderContent"><divclass="treeFolder"><spanclass="treeFolderInd">+</span><spanclass="treeFolderLabel">Sub-folder</span><divclass="treeFolderContent"><divclass="treeItem"my-action="doSomething"my-data="{arg1:'hello', arg2:'world'"my-tooltip="Goodbye"><spanclass="treeItemInd">o</span><spanclass="treeItemContent">
                Item text
               </span></div><divclass="treeItem"my-action="doSomethingElse"my-data="{arg1:'foo', arg2:'bar'}"my-tooltip="Another tip"><spanclass="treeItemInd">o</span><spanclass="treeItemContent">
                Item text
               </span></div>
            ...

The class names are used for CSS formatting. The various my-* attributes are the custom attributes that the client-side of the application uses to tie actions to when the user selects a tree node. We use a JSON string to represent in data, so dojo.fromJson() can be used on the attribute to get the data associated with the node (we internally cache the object created with the DOM node, so fromJson() does not have to be used each time the data is accessed.

Our load times have drastically improved, with now the browser itself being the one taken the most amount of time to parse the HTML, but it is no worse than loading a large web page. Once the HTML data is loaded and we registered our event hooks, expanding a node with 5,000 items is fairly quick. We basically just toggle CSS display setting to expand/collapse folders, so you are basically limited to how the browser itself performs.

Of course, one can create alternative structures to represent tree data, but I think you get the idea. We encapsulate the core functionality of the tree in a class with some virtual events to represent when an item is clicked and other tree actions. The user of the class just uses dojo.connect() to connect to which tree events of interest.

Side Note: Creating dijit.Tooltip instances for all the items was a significant factor in slow performance. To get around that, we manage tooltip rendering ourselves by using dijit.showTooltip() and dijit.hideTooltip() directly vs creating dijit.Tooltip instances.

One unfortunate thing for us is being stuck in IE7. IE7 degrades overall performance-wise when deal with large data sets, even if the system has plenty of RAM. IE8 and IE9 are much improved in this regard.

Solution 3:

You can try using Lazy Tree Grid along with Query Read Store. This does what you need. Lazy loading of children after eager loading of parents. Number of parent elements that needs to be loaded can also be controlled, with the grid.rowsPerPage