Tree control operation is too slow

[Mark_Yedinak]

No, this code was never posted publicly.

[LucianM]

Issue described by OP 8 years ago can be seen also on my system using LabVIEW 2018 SP1(f4) on Windows 7. I tried to replace the tree with all the other types with no change. Looks like a bug.

[Mark_Yedinak]

---

@LucianM wrote:

Issue described by OP 8 years ago can be seen also on my system using LabVIEW 2018 SP1(f4) on Windows 7. I tried to replace the tree with all the other types with no change. Looks like a bug.

---

How many entries are in your tree? I don't believe this is a bug but a performance limitation for large trees. It is possible to work with very large trees and still achieve good performance using methods I described earlier.

[cbutcher]

Here's a guess at perhaps something close to what Mark and (I think) Jack Dunaway (somebody_that_i_used_to_k) mentioned with Add Multiple Items to End.

If this wasn't the idea, maybe Mark can correct me 🙂

Here I generate a bunch of random strings (with mostly normal characters) and indent them randomly. The performance seemed fine for me when hovering/clicking/moving over late elements (on a fairly decent laptop). Populating the tree takes a short time, maybe a second or so. It's visible when you run the VI but not entirely debilitating, and I don't know how much of that is the generation of the array (no benchmarking carried out).

Probably the use of a class API to handle this would be more reusable 😉 and certainly more worth performance tuning over a quickly thrown together VI.

I delete the entire Tree before updating, because I didn't find a different way to set all elements. 

[Mark_Yedinak]

Yes, that is the general approach that I was referring to. With some smart array manipulation will allow you to add/delete branches in the middle of the tree. You manipulate the array and load the entire array in one shot. If the update is a single element you can manipulate the tree itself. Our class implementation maintains both the array version and the tree itself. Any updates are applied to both sets of data. Yes, this increases the memory footprint but performance is significantly improved.

[LucianM]

---

@Mark_Yedinak wrote:

---

@LucianM wrote:

Issue described by OP 8 years ago can be seen also on my system using LabVIEW 2018 SP1(f4) on Windows 7. I tried to replace the tree with all the other types with no change. Looks like a bug.

---

How many entries are in your tree? I don't believe this is a bug but a performance limitation for large trees. It is possible to work with very large trees and still achieve good performance using methods I described earlier.

---

Check the code from the 1st post. You need to run the VI once. It will populate the tree with 5000 entries. After VI execution stops, scroll down to the last element and just move the mouse over the tree. You should see LabVIEW using a lot of CPU.

[Dataflow_G]

The high CPU is due to the row height, or rather a custom row height. Try right-clicking the tree, then check Autosize Row Height. The CPU should drop to single digits. If Autosize Row Height is checked again there's no problem, until any of the rows is set to a custom height.

I guess LabVIEW is needing to do a whole bunch of calculations to determine the row the mouse is hovering over when a custom row height has been set, and the calculation only takes longer when you're looking at the bottom of the table (more rows to process). Otherwise the calculation is a simple multiply when the row height is constant.

[LucianM]

@Dataflow_G you're right! CPU usage drops significantly if Autosize Row Height is checked. Good to know. Thank you!

[musa_]

I do not get how it takes you only a second for the tree to populate, while I am doing something similar with the add multiple item to end method with 5000 element at once. for me it take more than a minute or so to generate the tree. Even with the little tricks I read in forums like defering panel updates etc. wont work well.

[musa_]

---

@cbutcher wrote:

Here's a guess at perhaps something close to what Mark and (I think) Jack Dunaway (somebody_that_i_used_to_k) mentioned with Add Multiple Items to End.

---

I do not get how it takes you only a second for the tree to populate, while I am doing something similar with the add multiple item to end method with 5000 element at once. for me it take more than a minute or so to generate the tree. Even with the little tricks I read in forums like defering panel updates etc. wont work well.