Poor performance when data is huge

[harit2101]

Hi,

There are about more the 35000 tree nodes. When ever I try to load, browser throws an error of long script and becomes unresponsive.

Was wondering is there any way we can tackle this issue and make the rendering fast for such a huge data. probably solution would be.

1. virtualization

[jakezatecky]

I never imagined this component having more than 10k nodes, but if we can get better performance, then I am all for it. There are two main areas in which performance takes a hit:

1. The in-memory calculations for checking/unchecking and expanding/collapsing nodes
2. The actual rendering of the DOM objects

The latter case would likely benefit from virtualization. There was a previous issue dedicated to performance that was resolved, but that mostly dealt with vastly improving the first point by reducing the calculation complexity from O(n*n) to O(n).

I'll keep this open, because I agree that virtualization of the nodes not visible in the viewport would be useful, I just have no idea how that would happen.

[harit2101]

Hey,

I have implemented the Virtualization in my project for tree but it is not generic and am not allowed to share, company policy . Would like to share the key steps and approach.

1. Removed all <ol> , <il> and child rendering code. Instead of this just added div for each node in TreeNode.jsx file.
2. Added two new props in NodeTree.jsx . a) rowIndex : its a numeric props helps in placing the row. Suppose index is 2 then it must be the second row to be displayed. For this row top = rowHeight * 2.. and so on for other rows b) level : it is used to add empty space at the start of the row. so it will appear as the child .
3. How am deciding rowIndex and level values from props Nodes. a) rowIndex :- Before rendering of checkBoxTree.jsx, looping through the props nodes and adding one new property rowIndex only when the expanded is true for that node. So that I can pass it to the TreeNode.jsx as a props. b) In componentWillProps method of checkBoxtree.jsx , adding the level to each node as property with the level in incremental order by looping through the node props . Like if top most parent then 0 . second top most then 1.. . and so on .
4. Calculation of number of rows to be displayed and start rowIndex and lastRow index to be displayed as per the screen size. a) Calculation of number of rows to display :- containerHeight / each row height b) Calculation of start rowIndex and lastRowIndex to display : Calculating as per the position of scroll bar. Example if position of scroll bar is top is 0 then start rowIndex would be 0 and lastRow depends on the height of container.

One more thing I have done to improve the performance is to load child nodes using service call when user click on expand icon. fetching the data from backed and displaying as childnodes on expand click.

[chiragswadia]

I am facing the same issue with about 50k nodes in tree. I have also implemented the same behaviour that onExpand, an ajax call is made which brings the child nodes and a new tree is rendered again. But, this does not solve the problem of poor performance.

Can someone suggest any virtual dom / virtual scroll plugin which can be easily integrated with the tree plugin ? Or is there any ETA on when this feature will be integrated in this plugin ?

Thanks

[harit2101]

Hi Chirag,

Below link would help you. It has Virtualization and expand collapse.

https://mleibman.github.io/SlickGrid/examples/example5-collapsing.html

[chiragswadia]

@harit2101 I need an virtual scroll integration with the checkbox tree plugin as I have gone way too far with the implementation in my project and using other plugin for listing a tree is out of question as of now.

[harit2101]

If this is the case then only option that I can recommend you as of now to add virtualization yourself .

[dtuyenle]

@harit2101 I am just curious. Are all nodes at the same level ? How deep is the nested tree ?

[RichestYoo]

I write this just as an idea for the owner of this repository (Not a solution for this directly for most users.)

In my case, the speed problem happend when I opened or closed a tree level with several thousand items. I reviewed the source code and found that all the item has its own ref so that any mass operation took place for all of them independently. After finding this, I made my own stuff similar to this, but the difference was I made a <TD> in put a table inside so that show/hide runs by changing only one parameter instead of all. Another change I made on my company stuff was to divide the number of units in one upload so that thousands cannot appear under one parent.

This is applicable to my case because I don't have "delete" in the tree; users delete items in the tree by checking items in the tree and clicking "delete" button outside the tree.