Rank: Advanced Member
Groups: Member
Joined: 6/14/2007
Posts: 36
|
Hi There,
I just wondered what is the upper limit for the number of nodes that can realistically exist in a tree before performance becomes an issue.
I did some very crude tests and found anything over approx 100-150 nodes took longer to build, and also found that the client-side expand/contract was slow (on the first click only).
I am assuming it was not designed to handle much bigger lists of nodes (under the same parent), and that populate on demand is the way to go for bigger trees?
Do you have any other suggestions for working with bigger trees?
Regards,
David
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,217
|
Hi David,
Yes. Populate on demand is definitely the way to go for big TreeView, that's what it is designed for. The TreeView has already been optimized to delay initializing invisible child nodes, that's why you notice a delay when you first expand a node. However all the node data are still loaded in memory, that's why it takes longer to load. Also, you definitely do not want to have a large number of nodes under the same parent node, because that obviously amplifies the delay, and populating on demand does not solve that delay. The exact upper limits depends on the machine and the TreeView configurations (styles, images, checkbox, etc), we've tried simple plain TreeView at 300 to 400 with acceptable result, but if you consider many users could have much older machines, it's always recommended to keep it much lower if possible.
Thanks
|
Rank: Advanced Member
Groups: Member
Joined: 6/14/2007
Posts: 36
|
Hi There,
Thanks for the quick response, you've confirmed what I suspected. We will take this into consideration when we design our UI around the tree.
Thanks again,
Regards,
David
|