I engaged a problem when using LabVIEW native tree control. It is shown in attach vi, and reproduce as blow.
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?
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.
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.
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.
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.
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..?
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.
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.