Dr. Damien's Development - Front Panel Control/Indicator Update Speed

[DFGray]

The relative update rates of various methods of setting controls and indicators is a frequent topic on these forums. I was curious about how these actually compared, so wrote a simple performance check for scalar (DBL), array ([U8]), and graph ([U8]). The results were sort of expected, but there were a couple of anomalies.

I tested five methods for setting front panel controls/indicators:

1. Terminal — the standard way to set a front panel indicator. Cannot be used for controls. Is asynchronous.
2. Local Variable — the standard way to set a front panel control. Can also be used to set indicators. Usually used in initialization and to handle multiple access points to the same control. Is commonly misused as a data repository. Is asynchronous.
3. Value Property — the standard way to set front panel controls and indicators in UI abstraction code. Usually used in conjunction with the Defer Panel Updates property on the panel, for performance reasons. Is synchronous.
4. Value (Signalling) Property — exactly like the Value property, but will fire events in the event structure. Is synchronous.
5. Control Value.Set VI Method — the standard way to initialize controls before pragmatically running a VI. Is asynchronous.

A priori, I would expect the ranking, fastest to slowest, to be terminal, local variable, control value set, value property, and value (signalling) property. In reality, things were a bit more complex. Here are the results I got using a 2.8GHz quad core Xeon test machine with LabVIEW 2011 SP1, f1 patched. The test code is attached. Tests were run with default parameters and run several times, with the lowest time recorded.

Control	Terminal	Local	CtlVal.Set	Value	Value(Signalling)
DBL	40.5ns	46.0ns	3.56µs	154µs	154µs
Array [U8]	93µs	93µs	567µs	1.17ms	251µs
Graph [U8]	91µs	90µs	743µs	1.16ms	13.6ms

The terminals and locals were indeed faster than anything else, with the Control Value.Set method and Value properties falling in behind. However, the Value (Signalling) property showed large variations. With the simple scalar, it is on par with the Value property. With a simple U8 array control, it is faster than anything but a terminal or local. With the graph, it is ten times slower than anything, probably due to the large number of events graphs produce.

The results are similar for LabVIEW 2009, with one major difference. Setting the terminal value for an array (graph or array indicator) is twice as slow as setting its local variable. This was fixed in either 2010 or 2011. The LabVIEW compiler team works on performance each release, so this kind of thing is expected.

Recommendations due to these tests do not change much. You should use terminals or locals when you can. For UI abstraction, use the Control Value.Set method when you do not need to fire events, and the Value (Signalling) property when you do. Alternately, always use the Control Value.Set method for UI abstraction and user events or task manager messages as needed. Modify as needed for specific control/indicator types.

Since it appears the Control Value.Set method is usually faster than the Value property for UI abstraction code, I created a VI which caches the VI ref and control name, taken from properties of the control. It is slower than setting the control with known values for these, but still faster than the Value property. You do get better performance if you cache the name and VI reference in your calling code (example in the scalar code).

I have included code for both LabVIEW 2009 and 2011. The 2011 code uses the high resolution timer in <vi.lib>, but that did not exist in 2009. So I used a set of high resolution timing VIs I have posted several times before (Windows only, since they use the Windows DLLs).

[Darin.K]

I'll add a link to an interesting topic which came up a while ago involving the Value property, as well as linked versus unlinked PNs. http://forums.ni.com/t5/LabVIEW/To-More-Specific-Class-or-To-Variant/m-p/1683838#M598573 Bottom line was to simply ignore the coercion dot when the Value property takes a Variant.

[GregFreeman]

I am assuming this is for execution speed during something like initialization, and not updating UI purposes? I wouldn't care much if I could update a UI at the nanosecond vs microsecond level, as I don't think my eyes would notice.

[Ben]

Thank you Dr Gray.

I ran your 2009 version a couple of times and my numbers varied from what you posted.

The Set Control method was twice as SLOW as the value-signaling and value method.

i alos noticed the Set Control method uses a lot of Kernal mode to execute while the other methods do not.

The local is showing as twice as fast as the terminal version which I will buy since the local has the "back door" thingy so I suspect the rapid updates are over-riding the previous and not making it to the GUI.

I am still taking these numbers with a grain of salt becuase speed of execution is not measuring the effieciency (work can be getting passed off to the UI thread for screen updates allowing the thread to continue)...

I am also curious about more than one of these benchmarks running in parallel since the interaction and bottle-necks that we find in real apps.

Ben

[DFGray]

The problem usually shows up when updating large numbers of front panel variables multiple times per second while simultaneously acquiring data, analyzing for the graphs, and maybe logging it.  For example, you are acquiring five analog channels, taking the power spectrum, streaming to disk, and displaying it all (waveforms and power spectra) on graphs 30 times per second.  This is pretty easy for a modern desktop, but not so easy for a netbook.  You try to save CPU cycles whenever you can.  As you said, however, in many cases, the Value property is not an issue.  But when I do a new design, I think about performance and, if possible, use locals or terminals for UI updates.  It is usually easier to design it efficiently up front than redesign it later.

[Ben]

The local being faster than a terminal flies in the face of what is sugggested for XControls.

THe other factor associated with locals in the number of locals in total.

There is more to this investigation than what meets the eye.

Ben

[DFGray]

Ben, what type of machine were you running on?  I reran the 2009 to verify my results, and the set control was always faster, by a factor of about two or much better, than the value property (but not value signalling).  Were you looking at value signalling?

My understanding is that the terminal, local, and set control all put the data into a transfer buffer and go on, allowing the UI to update at its next cycle.  The value properties wait until the control is fully updated before returning, bottlenecking the execution by the UI thread.  However, I have not tried these with parallel processing, so cannot comment on how well they perform in that context.

[Ben]

---

@DFGray wrote:

Ben, what type of machine were you running on?  I reran the 2009 to verify my results, and the set control was always faster, by a factor of about two or much better, than the value property (but not value signalling).  Were you looking at value signalling?

My understanding is that the terminal, local, and set control all put the data into a transfer buffer and go on, allowing the UI to update at its next cycle.  The value properties wait until the control is fully updated before returning, bottlenecking the execution by the UI thread.  However, I have not tried these with parallel processing, so cannot comment on how well they perform in that context.

---

Not sure.

It says;

Dell Optiplex 745

Intel Duo Core2

I got the same results (set Control is slower) runinng with 1K and 100K iterations.

LV 2009.

Ben

[DFGray]

Were you comparing to Value, Value (Signalling), or both?  And which test - scalar, array, or graph?

[Ben]

array version.

These are from the same machine but booted for LV 2010 running under XP.

Note the large kernal mode times!

So they are flip-floped from your findings using both LV 2009 and LV 2010.

Ben