In an application I add several nodes to each branch and add an object to the leaf of each branch.
I find this very slow, and the more leafes and nodes to add, the slower it goes.
It start out fast but then the efficacy decreases dramatically when more nad more leafes are added.
Is it the object adding that is so slow?
When doing this I find no difference in execution time using this method or the old-fashioned way of using the trees inherited with BDS2006.
Any tip?
Adding objects to leafes and several nodes on each branch
-
- Newbie
- Posts: 26
- Joined: Tue Apr 02, 2002 5:00 am
- Location: University of Oslo
- Contact:
-
- Newbie
- Posts: 26
- Joined: Tue Apr 02, 2002 5:00 am
- Location: University of Oslo
- Contact:
There may be up to 50000-100000 leaves, but already at about 1000 leaves (if unlucky, there are 5 nodes for each leave) adding suddenly start to go very slow. The same happens with tTreeView (which I use currently since trying teeTree gave no improvement at allTom wrote:Hi,
Can you provide some source-code to look at? Otherwise I'll try to provide some speed-tips. About how many nodes are you talking about? Have you looked at the speed-demo?
Regards,
Tom.
Yes, I have tried the demo, but there you only add a single node to the root.
The tree consists of name of country, name of county, name of community. standard name of parish and the text that user did enter in his program (different genealogy programs)
The routine is a presentation of a place name analysis done for Norwegian places, same for Sweden, Finland, Denmark and USA.
The data is stored in a tStTree container, adding the data to traditional stringgrids happens in a few seconds when there are 10000 analysed places to add, while using tTreeView or TeeTree takes nearly an hour
Is there a timing program that works with dbs2006 code? I tried some of the Turbopower Stopwatch and lineprofiler to measure what routine used the time, but they didn't work with dbs2006 Delphi, only Delphi 5
At moment I don't have any code since I outcommented the teetree part and am going to have an eye surgery on thursday and need to use time until then for other projects.
But in short, I add nation name to a root node, then counties for that country to the country node, then add communties (kommuner) to each county node, add parishes to each community node and the place names for the parish to the parish node. These are the leaves to which i add a pointer to the entry in the tStTree tree.
Could it be the adding of the object that slows down ?
Or is there a magic limit when passing about 20000-30000 nodes in total or earlier (have not measured exactly when things stop up running fast?)
Alf Christophersen
Dep. of Nutrition
Medical School
University of Oslo, Norway
Dep. of Nutrition
Medical School
University of Oslo, Norway
Hi,
I don't think you can compare a StringGrid with a Tree ifv of speed. These are two different things which are build for different reasons.
For each 'node' in a tree a node object must be created. Depending on the amount of features the node has, the more time it will take.
Another reason of speed issue, besides the drawing of the node is the way how the nodes are stored and thus retrieved/iterated.
Since both trees (teeTree and treeView) merely store a pointer to the real object, I don't think this is the issue with slows down the trees.
However, if you create the object at the moment you create a tree node it indeed will take some extra time (ie the creation of the object itself) and it takes more time, the bigger the object.
We've a small example demo which compares the speed between teeTree and the standard treeView. Ranging from 5.000 to 50.000 nodes.
Following lists the results of a test using Delphi 5 under Windows 2000 Server, on a Pentium III 650 Mhz with 256MB of ram, using BeginUpdate / EndUpdate. Results show the average time running the test consecutively 5 times. "Your mileage may vary".
Operation TeeTree Borland's TreeView % Better
Add 5000 nodes 90 msec 1142 msec 1269%
Add 10000 nodes 161 msec 4997 msec 2776%
Add 50000 nodes 1022 msec 167681 msec 16407%
Clear Tree with 10000 nodes 80 msec 4066 msec 5082%
This of course does not mean that teeTree is faster than a Stringgrid. A Stringgrid is a whole other kind of a component.
I've added some extra code to this demo, which enables to play with the amount of nodes/levels/objects added to the tree and to see the difference in time. I'll send the exe and sources to you by mail.
If you are working with lot's of nodes, I'm wondering if it is a good idea to load them all in memory at once. It might be better to load and show them on-demand. In teeTree you can use the OnExpandingCollapsing event for this purpose. Using this technique will improve your memory resources aswell. (Of course, you can only use the on-demand technique only if you don't need all nodes in memory)
Regards,
tom.
I don't think you can compare a StringGrid with a Tree ifv of speed. These are two different things which are build for different reasons.
For each 'node' in a tree a node object must be created. Depending on the amount of features the node has, the more time it will take.
Another reason of speed issue, besides the drawing of the node is the way how the nodes are stored and thus retrieved/iterated.
Since both trees (teeTree and treeView) merely store a pointer to the real object, I don't think this is the issue with slows down the trees.
However, if you create the object at the moment you create a tree node it indeed will take some extra time (ie the creation of the object itself) and it takes more time, the bigger the object.
We've a small example demo which compares the speed between teeTree and the standard treeView. Ranging from 5.000 to 50.000 nodes.
Following lists the results of a test using Delphi 5 under Windows 2000 Server, on a Pentium III 650 Mhz with 256MB of ram, using BeginUpdate / EndUpdate. Results show the average time running the test consecutively 5 times. "Your mileage may vary".
Operation TeeTree Borland's TreeView % Better
Add 5000 nodes 90 msec 1142 msec 1269%
Add 10000 nodes 161 msec 4997 msec 2776%
Add 50000 nodes 1022 msec 167681 msec 16407%
Clear Tree with 10000 nodes 80 msec 4066 msec 5082%
This of course does not mean that teeTree is faster than a Stringgrid. A Stringgrid is a whole other kind of a component.
I've added some extra code to this demo, which enables to play with the amount of nodes/levels/objects added to the tree and to see the difference in time. I'll send the exe and sources to you by mail.
If you are working with lot's of nodes, I'm wondering if it is a good idea to load them all in memory at once. It might be better to load and show them on-demand. In teeTree you can use the OnExpandingCollapsing event for this purpose. Using this technique will improve your memory resources aswell. (Of course, you can only use the on-demand technique only if you don't need all nodes in memory)
Regards,
tom.
-
- Newbie
- Posts: 26
- Joined: Tue Apr 02, 2002 5:00 am
- Location: University of Oslo
- Contact:
I should have added that the fast loading in a stringgrid shows that reading the objects that is to be stored a pointer to from the tStTree (a Turbopower Systool component) is not the rate-limiting processTom wrote:Hi,
I don't think you can compare a StringGrid with a Tree ifv of speed. These are two different things which are build for different reasons.
I think I have to test the routine that add the leaves might have some bad code or if it is the creation of the object pointer at that stage that use so much time.For each 'node' in a tree a node object must be created. Depending on the amount of features the node has, the more time it will take.
Another reason of speed issue, besides the drawing of the node is the way how the nodes are stored and thus retrieved/iterated.
Since both trees (teeTree and treeView) merely store a pointer to the real object, I don't think this is the issue with slows down the trees.
However, if you create the object at the moment you create a tree node it indeed will take some extra time (ie the creation of the object itself) and it takes more time, the bigger the object.
We've a small example demo which compares the speed between teeTree and the standard treeView. Ranging from 5.000 to 50.000 nodes.
Following lists the results of a test using Delphi 5 under Windows 2000 Server, on a Pentium III 650 Mhz with 256MB of ram, using BeginUpdate / EndUpdate. Results show the average time running the test consecutively 5 times. "Your mileage may vary".
Operation TeeTree Borland's TreeView % Better
Add 5000 nodes 90 msec 1142 msec 1269%
Add 10000 nodes 161 msec 4997 msec 2776%
Add 50000 nodes 1022 msec 167681 msec 16407%
Clear Tree with 10000 nodes 80 msec 4066 msec 5082%
This of course does not mean that teeTree is faster than a Stringgrid. A Stringgrid is a whole other kind of a component.
I've added some extra code to this demo, which enables to play with the amount of nodes/levels/objects added to the tree and to see the difference in time. I'll send the exe and sources to you by mail.
If you are working with lot's of nodes, I'm wondering if it is a good idea to load them all in memory at once. It might be better to load and show them on-demand. In teeTree you can use the OnExpandingCollapsing event for this purpose. Using this technique will improve your memory resources aswell. (Of course, you can only use the on-demand technique only if you don't need all nodes in memory)
Regards,
tom.
For some parishes, as much as 50-100 leaves should be added and for each leave, all the previous nodes has to be checked.
I'll also check that method mentioned. when someone click on Norway, then expand with all the counties known and so on. But then I need som help trees which store that information.
Well, this makes me think I just need some more dynamic data in the master source for all counties in order to mark what counties, communities or parishes are really mentioned in the place name harvested from each gedcom file.
Alf Christophersen
Dep. of Nutrition
Medical School
University of Oslo, Norway
Dep. of Nutrition
Medical School
University of Oslo, Norway
Offcourse I don't know how the data is grouped when you start creating the trees. But I think that with a good dataset you can achieve the 'on-demand' tree functionality easely.I'll also check that method mentioned. when someone click on Norway, then expand with all the counties known and so on. But then I need som help trees which store that information.
Well, this makes me think I just need some more dynamic data in the master source for all counties in order to mark what counties, communities or parishes are really mentioned in the place name harvested from each gedcom file.