Tree or ListBox or Array of Strings

[LHarris]

Is there any set of benchmarks or comparisons anywhere as to the advantages/disadvantages of using Trees, Listboxes or Arrays for display of text data?

I have a heirarchy of data (but it's a very flat heirarchy, only a couple of levels at the moment) that will be frequently updated and needs to be fully explorable by the user (ie, they have to be able to scroll or click or whistle or make faces or do something to get to look at any particular item on demand).

Currently I'm thinking that a tree would be the prettiest/best user interface, but slowest as far as updates go & most memory intensive, while an array would be a lot faster & easier to update, but not be so intuitive to the user. It's probably going to come down to how big a performance difference there is - so, anyone got any actual data on the differences?

Or just opinions and preferences?

[i know - this is LAVA, everyone has opinions ]

[Daklu]

so, anyone got any actual data on the differences?

Or just opinions and preferences?

No data, just opinion.

Present your data to the user in a way that makes sense to the user. If the user understands the data to be tree structured, put it in a tree control. It will save you grief in the long run, especially if you expect the data set to grow. (Imagine Windows Explorer presenting the folder structure as an array and you can see the headaches it would cause.)

Regarding performance concerns, how big is your data set expected to be and how frequently do you have to refresh the data?

[Mark Yedinak]

I don't have any specific numbers but I can state that trees con be rather slow for updating when there are a large number of elements. The way to improve this performance is to keep a separate 1D array which represents the tree and operate in this when you need to make changes. Use the property node for the tree to update the entire tree in one shot. Using this approach I have had trees with over 10000 elements in it and it updated fairly quickly. Certainly it was fast enough that it didn't cause user angst when working with it.

[LHarris]

Regarding performance concerns, how big is your data set expected to be and how frequently do you have to refresh the data?

Depending on the particular case, the data set could be as little as 100 items, or it could grow to as much as 20000 or more. Usually it will only be updating one or two items at a time, but this will be almost continuous (say update every second on average).

I don't have any specific numbers but I can state that trees con be rather slow for updating when there are a large number of elements. The way to improve this performance is to keep a separate 1D array which represents the tree and operate in this when you need to make changes. Use the property node for the tree to update the entire tree in one shot. Using this approach I have had trees with over 10000 elements in it and it updated fairly quickly. Certainly it was fast enough that it didn't cause user angst when working with it.

What was "fairly quickly" (milliseconds, half a second, a couple of seconds etc)? I can see that being a good approach to give me the flexibility of an array while the user gets the tree display as they want, but if I'm only updating one or two tree elements at a time, then reloading the whole tree might still take longer than individual changes. I'll have to give it a try & see.

Also, this would be at least a 2D array (there are 2 columns in the tree for now, but I can see possible future requests for more) so presumably that will take longer - unless Labview is just doing a memory blit for the loading.

I had assumed that the tree object was a collection of references, so if I had three levels, parent, child and grandchild, adding or deleting a grandchild would only affect the child branch it belonged to. However, the time taken to add or delete the grandchild seems to be dependent on the overall size of the tree (and the number of children) rather than the number of grandchildren on this branch. Which seems to suggest the tree is actually just a giant listbox anyway, with a few special features. Anyone know if this is the case?

[Tim_S]

I've used all three methods. I've also used a scrollbar as an offset pointer of which data to display. The method I used all came down to the best way to present the data in a clear, understandable way.

My experience with treeview controls is mixed. The treeview is great for displaying hierarical data, but is notoriously slow to update. My experience with the treeview is it can be extremely slow to update depending on how you use the methods and disable panel updates is your friend.

Tim

[jzoller]

What do the users want?

Usually, performance can be tweaked to work. User-tweaking, much harder.

Joe Z.

[LHarris]

What do the users want?

Usually, performance can be tweaked to work. User-tweaking, much harder.

Joe Z.

Actually, I can do some user-tweaking ... this is currently an internal tool so I can be "tougher" than with a paying customer. But still good to have a user-friendly interface .... as I'll get to hear all the complaints

In case anyone is interested - I tried a tree and an array of clusters (two ints for equivalent to tree childno & grandchildno, a bool for highlighting active line & two strings for the two tree columns). The items grew from 600 to 60000 over the course of the test. The tree was twice as fast at the low end (600 items), slowed at a fairly constant rate to about 30000 items, and then started to slow massively/exponentially. The array slowed at a marginally slower constant rate, but kept that all the way up to 60000.

I'm guessing I could've got better results from an array of just strings, and done conversions to numbers/bool as needed, but this was enough for my quick test.

So I'm going to go to the tree, but keep it small (only show the most "current" data) and dump everything in a logfile so it can be consulted if required.

[GoGators]

In both tree and multicolumn, if you are dynamically adding items make sure to use the "Defer front panel updates" property. The refresh on both is killer, and the deferring seems to make the performance go up quite a bit (in my case 5x for 100 sequential added items).

Personally the multicolumn is easier to use, but the tree often times makes more logical sense. If it is internal I'd use multicolumn to save time, and tree is it is a requirement.

[LHarris]

In both tree and multicolumn, if you are dynamically adding items make sure to use the "Defer front panel updates" property. The refresh on both is killer, and the deferring seems to make the performance go up quite a bit (in my case 5x for 100 sequential added items).

Personally the multicolumn is easier to use, but the tree often times makes more logical sense. If it is internal I'd use multicolumn to save time, and tree is it is a requirement.

Actually Defer Front Panel Updates didn't really help as there was usually only one or two items being changed at a time.

I did find one other odd item - I would've assumed that if I only needed to change the text on an item, that would be quicker than adding a new item. However, modifying the second column of text (set the item as active, change the active column number & change the string) was pretty slow - it was quicker to delete the whole item & add it back in with the amended text, even if this was the middle item of a thousand or so. So I'm guessing there is something cumbersome in how it handles the second column.