LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Controls[] Cluster Property slow to run

Hi,
I would like to register controls inside clusters for mouse events.
Since there are a lot of controls to register, I want to do it programmatically and I created a VI that searches for control refereces inside cluster with recursion.
The problem is that this code is too slow.

I have a main-cluster that contains 8 sub-clusters; each of the sub-cluster contains some sub-cluster and some controls.
As you can see in the figure I attached, it takes about 3 seconds to do the job, so it's too slow to run every time I load a page in my subpanel.
What's wrong? Is there another way to accomplish the task?

I'm using Win 7 64-bit and LV2012 SP1 32-bit. In the past I used this VI but I didn't find this behaviour.

Thanks in advance for any suggestion,
Alberto

 

 

GetClusterControls.vi (front panel):

GetClusterControls - Front Panel.png

 

GetClusterControls.vi (block diagram):

GetClusterControls.png

 

GetControlsRef.vi:

GetControlsRef.png

Download All
0 Kudos
Message 1 of 7
(3,730 Views)

I haven't looked closely at your code, but I suspect that the repeated resizing of arrays might be at play. I wouldn't expect it to have this effect with a relatively low number of elements, but I haven't analyzed it closely.

 

What I usually use for this type of stack based recursion is a queue. You add and remove elements from the queue until it's empty and you build a parallel array for the results. Haven't had performance problems with it.

 

Another option which might help you here is the Traverse for Reference VI. In later LV versions this should be under the scripting palette if you have scripting activated. If not, it should be in vi.lib\Utility. I think it traverses the entire VI, so you might need to filter out the results after it's done by checking the owner of each control to see which are in the cluster.


___________________
Try to take over the world!
0 Kudos
Message 2 of 7
(3,674 Views)

Hi tst, thank you very much for your suggestions.

At first i tried to use queues instead of arrays with same results. Then i gave a look at "Traverse for Reference VI", with even worse results (this VI uses properties and arrays as I do in my first try).

Then I noticed this: when I open "GetClusterControls.vi" (not run, just open), CPU usage gets higher (0% -> 13%, not so easy to discover with an Intel i7 4-core CPU).

When I run the VI and stopped it, CPU is still at 13%
I found the gulty: "Motors" control.
And now the magic thing: I change the background color of the cluster from transparent to white and now all is ok (loop time decreased from ~3000 to 40 ms).

 

I don't know if there is a bug or something else, but it's quite strange.

0 Kudos
Message 3 of 7
(3,656 Views)

LabVIEW, generally, due to its history and cross-platform support, has very limited hardware acceleration for UIs. This means that there are occasionally things which can cause serious slowdowns because the CPU is busy rendering overlapping elements and calculating alpha values instead of using dedicated libraries for it. It doesn't happen all that often, but it does come up. I ran across a similar performance issue caused by overlapping elements earlier this week.


___________________
Try to take over the world!
0 Kudos
Message 4 of 7
(3,654 Views)

It was the first time for me, thanks for explanation!

0 Kudos
Message 5 of 7
(3,639 Views)

I was wondering how can I discover if other pieces of code of my application suffers from these issues. I found the previous one by chance...

0 Kudos
Message 6 of 7
(3,523 Views)

LabVIEW has some profiling tools which can help you in the Tools menu and some versions ship with the Desktop Execution Trace Toolkit, which might also be able to help.

 

For things of this sort, which usually manifest with one clear symptom (probably high CPU consumption in this case), I sometimes debug them by disabling parts of the code to see when they disappear. You can use a binary search method by disabling roughly half the code in each iteration and that can make it fairly quick. This isn't always possible, but it can be a very effective method for finding the source of a problem.


___________________
Try to take over the world!
0 Kudos
Message 7 of 7
(3,501 Views)