10-25-2023 11:24 AM
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
Solved! Go to Solution.
10-25-2023 11:58 AM
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.
10-25-2023 12:00 PM
If you haven't already, use Defer Panel Updates
10-25-2023 12:10 PM
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.
10-25-2023 01:49 PM
@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.
10-26-2023 03:27 AM - edited 10-26-2023 03:30 AM
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.
10-27-2023 09:35 AM
I had to test, and a .NET tree view in "batch" mode is quite fast!
10-27-2023 10:49 AM - edited 10-27-2023 10:54 AM
@Yamaeda wrote:
I had to test, and a .NET tree view in "batch" mode is quite fast!
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 😑)...
10-27-2023 08:00 PM
I tried 1000 mains with 50 childs each and it was 1.67 secs on my laptop. 🙂