Speeding up the Tree Control

[John Lokanis]

Note: My comments apply to LV8.20. If you are using a newer version, YMMV...

I have been trying to find a way to manage the Tree Control better in my code. I use a Tree to show the results of a series of tests. This works nicely since the tests are hierarchical in nature. My system can test many DUTs at once but I only display the results on one DUT at a time. So, I build a parallel data structure to hold the information normally written to the tree and I only update the tree when the user selects a certain DUT. This eliminates writes to the tree control except in cases where the user actually want to see the detailed data.

Unfortunately, writing to the tree is VERY slow. Adding items is quick when you use Add Multiple Items To End, but if you also want to set the colors of individual cells, then it is painstakingly slow.

The usual tricks of Defer Updates helps a little, but not much. So, I came up with an experiment to see what can be done about this. My discovery was that the order you access the tags in the tree dictates how slow that update is. If you write your changes form the first tag to the last, each write gets slower in an exponential manner. If you update in reverse order (last tag first) then the write speed is more constant (and quicker on average). Even so, it is still ridiculously slow.

I have attached a VI that demonstrates these effects. Take a look and try the various options. Please post your results here and if you find a better solution. As for me, my best results were with Defer Update on, Update Tags in reverse and Write Tag with each update. (the defaults of the VI). In this instance, it took about 49 seconds to run the VI.

thanks for any ideas you can add.

-John

[Mellberg]

Well, I think you should consider skipping the coloring and then also writing the data_1..data_2 as 'Child Text'.

Also, skipping writing the Child Tag will give the item the tag of 'Left Cell String' - not sure if that will speed things up, but perhaps...

Modifying your example, making it give the same result, except the coloring, the run-time went from ~30 sec to ~1 sec on my machine, using LV8.2.1.

Hope it could be of some use... :-)

//Mellberg

[John Lokanis]

Unfortunatly, the coloring of the cells is an integral part of my display, so eliminating that is not an option. I will try your idea about only changing the color in the for loop and moving the symbol and test changes to the Add function call. If only I could specify the color of each cell in the add function...

Thanks for the idea.

[silmaril]

QUOTE(jlokanis @ Oct 24 2007, 07:57 PM)

Unfortunatly, the coloring of the cells is an integral part of my display, so eliminating that is not an option. I will try your idea about only changing the color in the for loop and moving the symbol and test changes to the Add function call. If only I could specify the color of each cell in the add function...

In a table you can use "-2" as the "line" coordinate to color a whole column in one step, which works pretty fast.

I didn't find an equivalent for this in the tree control properties.

Is this really missing, or was it just me who missed it?

The fastest way I found to make large changes to a tree control is still hiding the tree until I'm finished.

This doesn't look very nice, but it works.

[robijn]

QUOTE(jlokanis @ Oct 24 2007, 03:53 AM)

update the tree when the user selects a certain DUT. This eliminates writes to the tree control except in cases where the user actually want to see the detailed data.

I've also wanted a tree control to display a lot of info. I wrote a small lib a couple of years ago that tries to limit the required action on the tree control as much as possible, i.e. only add new items, only update changed cells etc. It also integrates better into your dataflow, with cell strings, colours and item glyphs flowing in (or out)... You can find it at http://robijn.net/labview . I have lately discovered a bug with items at the end, and I have updated code ready but not placed yet...

Joris

[Norm Kirchner]

Quick side note, and gratuitous plug.... Don't forget to checkout the Tree Control API in the code repository. Although may not be faster while running, it will be much faster to program.

[Aristos Queue]

QUOTE(silmaril @ Oct 25 2007, 03:03 AM)

The fastest way I found to make large changes to a tree control is still hiding the tree until I'm finished.

This doesn't look very nice, but it works.

Just use "Defer Panel Updates" instead of hiding the specific control. Same effect, looks better to users. And if the update is long, use the "Set Busy.vi" to turn the mouse cursor into an hourglass and lock out the interface. (Unset Busy.vi to clear the hourglass).

[John Lokanis]

Well, I think I have this working as fast as possible now. Since the only feature of the cell that I use and that cannot be defined with the Add method is the color, I have changed my code to only write color changes to the cell properties for new rows. This sped it up a bit but it is still quite slow. I also am using a dialog box with a progress bar to entertain the user while the color updates are completed. I used a few tricks to only show this dialog for long updates (more than 300 rows).My GUI design requires each row to potentially have a different color in a specific cell. This is because I am using the tree to show test results and I want to color the cell that shows PASS or FAIL in green or red, respectively. So, the idea of coloring a whole column at once would not work, unfortunately.the real solution here is for NI to extend the Add method to include inputs for setting the cell colors, fonts, text sizes, etc... This could be done by passing in arrays for the child cells and element for the leftmost cell. This would allow the functionality of the control to be extended while still being fully backwards compatible with the current implementation. The Add method really needs to support all elements of the control.Another alternative would be to create a data type that could store all the tree information. Perhaps a typedef's cluster or arrays of clusters? The point would be to be able to write this data to the tree control in one action and have the tree display the data instantly. That would allow the developer to build up this data structure in their code quickly and only write it to the control for display when the GUI is needed by the user.Anyways, I hope someone at NI is paying attention...

-John

By the way, nobody seemed to notice or comment on the fact that writing the cell colors from the last tag to the first is faster than writing from the first to the last. Doesn't this seem strange to anyone? My first guess what it was a memory allocation effect (by writting the last tag first, you allocate the memory for all the cell colors at once) but this seems strange since the Add method should be allocating the entire memory structure at once. Any ideas?

[Ton Plomp]

QUOTE(Aristos Queue @ Oct 25 2007, 07:02 PM)

Just use "Defer Panel Updates" instead of hiding the specific control. Same effect, looks better to users. And if the update is long, use the "Set Busy.vi" to turn the mouse cursor into an hourglass and lock out the interface. (Unset Busy.vi to clear the hourglass).

Get a picture of the tree control, put this into a hidden picture control, show the picture control, hide the tree, edit the tree and reverse.

Ton