I am surprised by so bad figures. I have experienced large trees 1800 nodes with better performance. But this experience is dated and it is possible that the latest version of the graphical layout is responsible of your problem. I will try again. Could you mail me or post the parameters you have selected for the tree creation.
Nevertheless, about handling large trees (e.g. your file system) I recommend to use AjaxTree derived from dftree in the same project. The idea is to load only nodes used for display. Let say that from a 1400 nodes tree, only a few are displayed on screen. AjaxTree in lazy mode loads only opened nodes and their direct childrens. Then the display performance is no more an issue.
Sincerely, Ben
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Below are the figures using AjaxTree (it is identical to dftree, but use Ajax to load the definition). We can indeed observe that the time elapsed in the node creator is the larger. The assumption about graphical layout can be discarded. I suspect a too simple implementation in the node search algorithm (Currently it is a sequential search. A hashed list should be faster but less general). I will investigate as soon as possible.
Sincerely,
Ben
Count of nodes = 1779 nodes
globalTime=35480 ms
_TransferTime=5764 ms
_XMLParsingTime=8 ms
_getCookieTime=68 ms
_nodeCreationTime=29270 ms
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
At the end, the firebug plugin of firefox has highlighted that the method dFTreeDefaultLayout._clean_table took() 58% execution time. Thus the problem was well liked to the graphical layout. It was the first assumption. The version 0.2.6 optimises calls to this method. Now performance should be acceptable for large trees even if they are built by once when the page is loaded (it is not the recommended way - AjaxTree is better).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Building a tree with 1400+ nodes takes minutes to execute on a typical computer. Even with isLazy:true the performance is unacceptable.
Hi,
I agree with you: it is unacceptable.
I am surprised by so bad figures. I have experienced large trees 1800 nodes with better performance. But this experience is dated and it is possible that the latest version of the graphical layout is responsible of your problem. I will try again. Could you mail me or post the parameters you have selected for the tree creation.
Nevertheless, about handling large trees (e.g. your file system) I recommend to use AjaxTree derived from dftree in the same project. The idea is to load only nodes used for display. Let say that from a 1400 nodes tree, only a few are displayed on screen. AjaxTree in lazy mode loads only opened nodes and their direct childrens. Then the display performance is no more an issue.
Sincerely, Ben
Below are the figures using AjaxTree (it is identical to dftree, but use Ajax to load the definition). We can indeed observe that the time elapsed in the node creator is the larger. The assumption about graphical layout can be discarded. I suspect a too simple implementation in the node search algorithm (Currently it is a sequential search. A hashed list should be faster but less general). I will investigate as soon as possible.
Sincerely,
Ben
Count of nodes = 1779 nodes
globalTime=35480 ms
_TransferTime=5764 ms
_XMLParsingTime=8 ms
_getCookieTime=68 ms
_nodeCreationTime=29270 ms
At the end, the firebug plugin of firefox has highlighted that the method dFTreeDefaultLayout._clean_table took() 58% execution time. Thus the problem was well liked to the graphical layout. It was the first assumption. The version 0.2.6 optimises calls to this method. Now performance should be acceptable for large trees even if they are built by once when the page is loaded (it is not the recommended way - AjaxTree is better).