LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Tree control operation is too slow

I engaged a problem when using LabVIEW native tree control. It is shown in attach vi, and reproduce as blow.

 

  • Generate more than 1000 items in a LabVIEW tree control
  • Move the vertical slide bar to the end the list
  • Quickly Move mouse inside the area of tree control, then the CPU usage will be high until I stop move the mouse. Even I did not run the vi.

The main problem is that when I do any operation on the item which is bigger than 1000th,  the whole program hang up to wating the tree action. Even I just quick move my mouse over the tree items. But it would not happen in 0 to 800 items.

 

Have anybody seen that before?

How to resovle this issue?

 

Thanks

Message 1 of 18
(4,896 Views)

Hi MoonSailer

 

I'm Jamie an Applications Engineer at NI UK.

 

Adding individual elements to a tree is faster if you defer panel updates before the loop and then restore front panel updates after the contents of the tree has been generated. Please look at the forum here which details a similar issue and also the community example here which outlines how to enable and disable front panel updates.

 

Hope this helps with your application MoonSailer.

 

Thanks

 

Jamie

Jamie S.

Applications Engineer
National Instruments
Message 2 of 18
(4,876 Views)

When dealing with very large trees it is fastest to add the data to the tree using the flattened array structure of the tree. You can see this format if you get the elements of the tree from the property node. We developed a LVOOP class the works very nicely with very large trees. Within the class we have both the tree control and a flattened representation of the tree data. Any changes to the tree we make in both places. Adding large amounts of data is accomplished by first updating the flattened structure and then updating the tree itself with all the data at one time. Unfortunately we do not have the permission yet to post this class. We are in process of trying to do that. In the mean time it does give you an idea of how to improve performance. BTW, we deal with trees that have over 10000 elements and our performance is very good. We have benchmarked this implementation against several various implementations we have found online and performed better than all of them.

 

Hopefully we can post this code soon.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 3 of 18
(4,852 Views)

Thank you for your reply.

 

Actually, This issue is not adding item problem. What’s I tried is that after adding multiple items to the tree, even the VI is not in running state just leave it in edit mode. When I move my mouse over items bigger than 1000th,  the LabVIEW runtime will take almost whole CPU usage.

high cpu usage.JPG

Message 4 of 18
(4,823 Views)

Hi MoonSailer,

 

Running your vi and moving the mouse cursor over tree elements larger than 1000 does not cause a large spike in CPU usage on my machine running Windows 7 and LabVIEW 2011. From you screenshot I can assume you are running Windows XP however what version of LabVIEW are you running?

 

It may be worth implementing my previous solution regarding delaying updates to the front panel until after the data has been populated just to see if that makes any difference although I am aware the issue also occurs when the code isn't running.

 

Hopefully by running the code on XP and your version of LabVIEW I will be able to recreate your issue.

 

Thanks

 

Jamie

Jamie S.

Applications Engineer
National Instruments
0 Kudos
Message 5 of 18
(4,802 Views)

I can see it on my system as well. Move the cursor over the three at the first element, my cpu usage is 0-1%. if I scroll down to the 5000h element, and then move my cursor, the cpu usage is 25%. I am running labview 2011 on win 7...

 

My guess is that labview calculates the cursors position in the three element..?

 

0 Kudos
Message 6 of 18
(4,796 Views)

My laptop is like this:

 

Mode: Lenovo K43G

CPU: Intel(R) Core™ 2 Duo CPU T6400@2.00Ghz

OS: WinXP SP3

Version: LabVIEW 2010

Version: LabVIEW 2009

Version: LabVIEW 8.6.1

 

Even I tried it on ThinkPad R400 with Win7, the issue happened on it all the same.

 

I tried to build it to application, but the issue remains.

 

Maybe LabVIEW runtime is capturing the mouse move event, though VI is not running. When the item number is too big, it will take a huge CPU usage to index the big 2D array with other tree's properties.

 

0 Kudos
Message 7 of 18
(4,780 Views)

Anyone has ideas about that

0 Kudos
Message 8 of 18
(4,732 Views)

@Mark_Yedinak wrote:

When dealing with very large trees it is fastest to add the data to the tree using the flattened array structure of the tree. You can see this format if you get the elements of the tree from the property node. We developed a LVOOP class the works very nicely with very large trees. Within the class we have both the tree control and a flattened representation of the tree data. Any changes to the tree we make in both places. Adding large amounts of data is accomplished by first updating the flattened structure and then updating the tree itself with all the data at one time.


Mark, can you go into more detail on this "flattened array structure"? Are you just referring to the "Add Multiple Items to End" array of clusters, or is it more like the illicit opcodes for pictures? Also, do you have a clever way of bulk-retrieving all items at once from the tree, or is data retrieval from your API just using the cached value in the class?

 

Direct manipulations to the tree such as drag/drop, deletions and additions could be monitored by a watchdog process in the class to ensure synchronization with your cached tree data, but this just feels "heavy" and laborious to reinvent -- wondering if you're sitting on some super cool backdoor or undocumented features or tricks for bulk-retrieving data.

0 Kudos
Message 9 of 18
(4,582 Views)

Mark,  Did you ever post this code?

0 Kudos
Message 10 of 18
(3,617 Views)