LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Tree control operation is too slow

No, this code was never posted publicly.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 11 of 18
(1,709 Views)

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.

Lucian
CLA
0 Kudos
Message 12 of 18
(1,678 Views)

@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.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 13 of 18
(1,658 Views)

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 🙂

 

Example_VI.png

 

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. 


GCentral
Message 14 of 18
(1,647 Views)

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.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 15 of 18
(1,642 Views)

@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.

Lucian
CLA
0 Kudos
Message 16 of 18
(1,624 Views)

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.

Message 17 of 18
(1,596 Views)

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

Lucian
CLA
0 Kudos
Message 18 of 18
(1,565 Views)