LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Quick Load a Tree?

Solved!
Go to solution

I have a dialog box that presents a tree with a lot of items.  The tree is loaded from a file* and the load time is a bit annoying.

For normal calls, I have it load the tree on the first call only.  But there are some calls that reload the VI every time ** so each call is a "first call".  This results in the dialog VI reloading the tree each time.

 

Is there any trick to quick-load a tree?

 

* A file that almost never changes

** And that's beyond my control

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 1 of 9
(1,669 Views)
Solution
Accepted by topic author paul_cardinale

Are you turning on "Defer panel updates" when you add the nodes to the tree?

 

If I add 1000 items to a tree un-deferred, it takes ~2.6 seconds.

 

If it is deferred, it takes 0.1-0.2 seconds.

Message 2 of 9
(1,646 Views)

If you haven't already, use Defer Panel Updates

0 Kudos
Message 3 of 9
(1,641 Views)

I have struggled with fast tree based file browsing of a remote machine. I ended up indexing the file system of the remote in the background and creating an XML file with the entire file system represented in XML maybe similar to your file*. The file browser tree UI object is a singleton that only exists in a popup VI on the local machine that is running but hidden so it can load the tree in the background. When the user gets around to opening the file browser it is already loaded and ready to go browse. 

 

 

 

 

______________________________________________________________
Have a pleasant day and be sure to learn Python for success and prosperity.
0 Kudos
Message 4 of 9
(1,632 Views)

@Kyle97330 wrote:

Are you turning on "Defer panel updates" when you add the nodes to the tree?

 

If I add 1000 items to a tree un-deferred, it takes ~2.6 seconds.

 

If it is deferred, it takes 0.1-0.2 seconds.


Gee, I knew that; but I'm getting more forgetful in my old age.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 5 of 9
(1,593 Views)

The main problem with trees (and IIRC enum, ring and combobox items) is the time it takes to add items is exponential growing with the number of items. Even with defer panel updates on (or the tree hidden).

 

There's a tree method to add bulk elements. But it's limited and, in my experience, it isn't much faster and if it takes long, it hangs LV until it's done.

 

What can help is 'lazy visualization': only show parent items with a dummy child if they have 1> children. Then populate the children (again with dummy child) when the user expands the parent... Not trivial to implement, and it only helps for non-shallow trees. And obviously it only works if the initial view has all items closed.

Message 6 of 9
(1,531 Views)

I had to test, and a .NET tree view in "batch" mode is quite fast!

TreeView NET.png

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
Message 7 of 9
(1,446 Views)

@Yamaeda wrote:

I had to test, and a .NET tree view in "batch" mode is quite fast!

TreeView NET.png


And it scales up much better.

 

LV seems to check each added item against all existing items (to create a unique tag I assume)... This gets old (or slow) fast.

 

Even 20000 parents with 2 childs is reasonably fast (few seconds). LV will take much longer (6 seconds), and after adding the items the FP is non-responsive for much, much longer (2 minutes 😑)...

0 Kudos
Message 8 of 9
(1,437 Views)

I tried 1000 mains with 50 childs each and it was 1.67 secs on my laptop. 🙂

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 9 of 9
(1,408 Views)