How to improve XControl performance?

[SnowForest]

Hi All,

LabVIEW 2009 + DSC

In following project example there are XControl 1 and tester.vi. My target was build flexible display object (XControl 1) because my user interface is varying lot depending current customer configuration. The amount of these XControls are typically 100-200 pieces per display. The problem is that this code structure generates lot CPU load(even it is very simple). This can be seen easily when tester.vi is set to run. In generally is there any way to improve XControl perfomance?  

[Jan_HeG]

You are a bit optimistic when you are posting the 2009 version, not that many have had a chance to get their hands on it yet 

Message Edited by Jan_HeG on 08-06-2009 07:26 AM

[altenbach]

I am still at NI week, so I don't have much time to look into that, but I would try to avoid overlapping objects in the xcontrol (and also make the numeric indicator large enough so the "100" is not clipped). See if performance improves...

[SnowForest]

Hi All,

Very good point that all haven't yet installed newest version. Now example is also saved in 8.6 version.  

[DFGray · Accepted solution]

Some ways to increase performance:

1. Never use a Value property when you can use a local variable.  The difference in speed is two or three orders of magnitude.  You have several instances of this.
2. Consider changing your data structure so that Object number and Object position are parallel arrays.  This allows you to easily search Object number using the Search 1D Array primitive, then extract the proper element from Object position using Index Array.
3. You really should not have anything in the XControl which will halt or delay execution, since this will lock your UI thread.  Your popup VI does this.  If you need to pop up a dialog, launch it with the Run VI method with Wait Until Done set to FALSE and Auto Dispose Ref set to TRUE. To communicate the result back to the XControl, drop a hidden control on the front panel of the XControl, pass a reference to this control to your dialog, then use the Value (signaling) method to communicate back to the XControl from the dialog.  Use a Value changed event on the hidden control to handle receipt of the data on the XControl.

[SnowForest]

Hi,

Thank you very much for these tips. I will implement these tips and do some tests.

This popup dialog (point 3) can be launched only when calling VI is not running. This XControl's main target is to help customize our user interface. So this popup will be launched only once per application (when programmer is doing customation). Is this point 3 really an issue if  popup can be launched  only when VI is not running?

[DFGray]

Make sure you follow Altenbach's tip, as well, since it can give you a huge performance boost.

I am not an XControl expert, so I cannot definitively answer your second question.  I do not think it would be a problem, but do not really know.  However, as a developer, I am very leery of anything which can be misused or copied and misused in the future.  If you leave it, make sure you put big warning text labels around it so no one copies it for runtime use.  My personal preference would be to fix it.

[SnowForest]

Hi,

I  implemented all performance tips which where suggested. I didn't noticed signifigant improvement. This means that my computer CPU load is 86% while running "tester.vi". I also disabled "allow debugging" option from facade.vi. This decreased CPU load to level ~80%. Still CPU load level is a far away from that level what we need. I changed yellow led-indicator to yellow decoration. I also relocated indicators and decoration so that there is no overlapping.

It seems that only way get this code effcient is change overall structure. Of course if I only update those XControls whose values are changed code performance will be better. That needs huge event structure or something else. Also the updating of our display must be done "manually". So after all there is no reason use XControl...

Newest version is attached

[DFGray]

Your XControl is probably about as efficient as it is going to get.  You could wring a bit more performance out of it, but I don't think it will be significant (execution time was 1ms on my machine, about 20% CPU time - 3GHz Intel Core2 Duo running Vista64).  I agree with you that your best bet is to only update the controls you need to update, especially since you have this information.  You are also correct, that to be efficient, you would need a giant case structure containing the terminals or locals.  You could do it inefficiently, but more transparently, by using the Value property and an array of references, but given your computing constraints, I would not recommend this.

[Ben]

Ideas that may help performance.

1) Track the previous values displayed and only update the indicators when they change. In my X_Controls I wrap the terminal in a case so I only update the FP if a change happened.

2) Instead of using an array of cluster try using two arrays so you can do a "search 1d array" rather than unbundling and comapring element by element.

3) Make "Object Postition" a "U8".

Just trying to help,

Ben

Message Edited by Ben on 08-11-2009 08:53 AM