Tree control creation is too slow

[Jarrod_S.]

You can also access the double clicked item directly from the Event Structure left data node itself. You should see an output called Tag which will give you the double clicked item string.

Message Edited by Jarrod S. on 06-14-2006 12:36 PM

[J.R.]

Hello Jarrod,

Ok thanks. It helps us but I misunderstood the customer. He want to make something like an interactive FamilyTree : only add or substract the expanded or collapsed part of the tree with the little + or - as in a windows tree and redraw the tree each time with the corresponding elements only. Why he want to do that? To not load all the elements at the beginning.

Thus our question is : Is there a property from which I can access the current + or - expanded or collapsed? After a while searching in all the properties about the tree I wasn't able to find a property like this one described above.

could you help us? Or maybe do you know where we can find a property like this?

Thanks for your help and the time you spent for us.

Kind Regards,

[CoastalMaineBird]

For the record, I just timed the alternate ways of doing this.

In LV 2013SP1, I have 3 domains, each with 4 devices, each with 4 modules, each with 10 channels - that's 543 items altogether.

Using the ADD ITEM method (one at a time) it took 4300 mSec.

Using the ADD MULTIPLE ITEMS method, it takes 17 mSec.

[GoofyWires]

Using Darren's benchmark I changed the count N and increased it. 

For N=40000 (200000 elements) it took LV 2016 32bit almost 15 minutes.

The sad yet not surprising discovery was that the time wasn't increasing linearly.

I doubt it is because the tree is not initialized to the expected size.

From my experience it is because the FP has so much data on it (stupidly LV allocates memory for elements which are not currently displayed) and it slows it down. 

Moreover, I guess that adding multiple elements still adds element by element and just applies the defer panel update.

It makes me want to hack the binary code of a tree and bulk create it myself.

[CoastalMaineBird]

stupidly LV allocates memory for elements which are not currently displayed

So, if allocating memory is "stupid", how would you propose to operate the display when the user changes what he wants to see?

How would you propose to respond to the GET PROPERTIES for tag X, if X is not displayed?

[GoofyWires]

MVC...

The FP should be just the View and not a DB.

If there is a variant/tree/table on the FP the FP should allocate just enough space for what is currently displayed.

When I scroll through the displayed item the FP should update itself from the Model and cycle the displayed data not requiring additional memory maybe applying a cyclic buffer.

I can't count the number of times memory stuck vis where solved by moving the data to a subvi and/or preventing the FP from turning into a DB. 

I attached a vi with a tree benchmark. Try changing the loop count and the child array size.

[rolfk]

A LabVIEW control is an object with a Model (the interface with properties and methods), a View (the front panel control) and a Controller (the internal implementation that manages the state of the control). What you suggest would mean that a LabVIEW control can not have any state. Where would it take the information to update the control view when the user scrolls? You want to maintain all that yourself somewhere and get a callback invoked that requests the information from you?

That's of course possibly but burdons you with the work of somewhere somehow storing those strings too and they still get allocated, just not in the object itself but in your software. But that is not how LabVIEW controls work, although you can of course make them behave like that using the VI server interface and doing all the nitty gritty work yourself.

[GoofyWires]

First, Rolf, respect. 

Not trying to argue here but I would expect NI to carry the burden. I know that this is how LV works. 

I did implement it a while back in a company I worked for yet I couldn't take the code with me and I don't have the time to recreate it.

The suggestion doesn't contradict the controls in the View from having a state. They have a state describing what they show from the Model and how they show it.

If by state you mean a snapshot of the entire model in any given moment then no, the river of constantly changing data is maintained only in the model with asynchronous calls taking parts of that blood stream to the view and that view might be outdated.

At the moment, if you want to create a new data to use, you must add a new control to hold it on the FP.

Mixing the View and the Model brings a lot of bugs to LV once you start to use more than several data points. 

Back to the issue, I have 200K lines to add to a tree. I have all the arrays pre prepared. I just want to display it in the tree.

Moving the data from one array control to another array control takes zero time. Why shouldn't it be the case once I populate a tree?

Why adding 100 lines take exponential more time each time I add 100 more lines?