LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Adding elements in tree Efficiently

Solved!
Go to solution

Hi,

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 )

0 Kudos
Message 1 of 11
(3,259 Views)

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!

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 2 of 11
(3,237 Views)

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

0 Kudos
Message 3 of 11
(3,223 Views)

You placed the defer OUTSIDE the loop? It sounds like you put it INSIDE the loop.....

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 4 of 11
(3,220 Views)

Please check the vi.

 

0 Kudos
Message 5 of 11
(3,216 Views)
Solution
Accepted by topic author RJ2Learn

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?

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Message 6 of 11
(3,205 Views)

Thanks Norbert,

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......... 

0 Kudos
Message 7 of 11
(3,196 Views)

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.

 

http://lavag.org/topic/17009-labview-2013-favorite-features-and-improvements/

0 Kudos
Message 8 of 11
(3,177 Views)

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

0 Kudos
Message 9 of 11
(3,165 Views)

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.

0 Kudos
Message 10 of 11
(3,160 Views)