03-26-2015 04:17 AM - edited 03-26-2015 04:32 AM
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.vi (block diagram):
GetControlsRef.vi:
03-27-2015 04:38 AM
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.
03-27-2015 08:35 AM
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.
03-27-2015 08:49 AM
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.
03-27-2015 09:28 AM
It was the first time for me, thanks for explanation!
05-06-2015 03:39 PM
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...
05-07-2015 12:40 AM
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.