I am trying to add elements in tree.
The problem i am facing is, i have to update the tree continously and add elments to it .
For adding first few elements it is taking less time but as the tree grows the gets accumlated.
Demo Vi is attached for reference.
aNY HELP WILL BE GREATFUL. ( vi ATTACHED IS IN 2009 version )
Solved! Go to Solution.
Adding new elements will for sure take more time the more elements you already hae in the tree.
But the main issue for the time you see is front panel update.
I recommend you to disable front panel update before entering the loop and re-activate it once you left the loop. This will (at least on my machine) cut the time taken for 1000 elements by more than six times!
Thanks, I tried Defer panel update but on my PC i am getting the following results
with Defer panel update - 10553 ms
without Defer panel update - 10454 ms ( Default value set for controls in both cases )
My PC configuration is Pentium(R) CPU G640 , 2.80 GHz
RAM - 4 GB , LabVIEW - 2009 on Windows 7 Professional SP1
Any additional info ......
Thanks for Reply
You placed the defer OUTSIDE the loop? It sounds like you put it INSIDE the loop.....
First off, 1% discrepancy for time benchmarking on Windows is "no difference".
But indeed, update of front panel is not the limiting factor here: It is the number of child-entries which are creating issues. So with zero children (as i had in my first test), defer updates does grant you a huge performance increase as this is the one and only overhead.
In your case (100 children), defer updates is off relevance as the "Add Items" method is taking quite some time.
I concur that the performance impact is huge, maybe too huge, for increasing number of children. But on the other hand, you have to understand that you are dealing with arrays of cluster... so it is indeed a big effort for the memory manager to allocate enough memory, copy things around and (internally) de-allocate memory. The more data is involved, the more overhead this will create. Therefore, it WILL get slower the more data you add. But granted, the extend is surprisingly high.
But nothing you can change.
At last comment: Why do you need a tree which changes a lot of times during execution while maintaining several 100ths of items in any combination of parent/child?
Yes i know that this 1% ( or even if it would have been 2% ) difference in benchmark, may be there in Windows.
Even i know that as the number of childs incresese we get more hit in performance. ( i ran the test with different combinations and yes you are correct )
As per your last comment - I have an application in which i really need to do this.
Now my last comment is - I just wanted to know that "But nothing you can change"
still if there is any work around i will be happy to know that.........
I'd be curious to see the code. I suspect using the Add Multiple Items is more efficient, than adding them one at a time.
I also recommend the defer front panel, but it isn't always good enough it just makes it slightly better.
Also in 2013 NI revamped several routines for drawing trees, tables, and listboxes. A discussion took place on LAVA.
Ran the code on LabVIEW 2013, Win 7 , 2.40 GHz
The result i am getting with or without Defer Panel Update is almost 12000 ms.
so whats going on here , No improvement from 2009 to 2013 or the specific case itself has some problem
if i am not wrong Defer panel update should have minimized calls to UI thread
Sorry I didn't fully read the post before posting last. I see you are already using the Add Multiple Items, and defer panels. This does take a very long time to update. I even tried changing the code to only use one Add Multiple Items and it still took about the same amount of time in 2013 SP1.