Reference Variables and slow performance

[Newbie217]

Hello,

Lately I have been writing a lot of programs using reference variables. The primary reason is I like to split my programs into multiple vi's to make them easier to read. The reference variables come in handy when I am running subvi's that execute long for loops, because I like to return indicator values to the main vi front panel. For the most part, everything works well, but I have started to notice that the programs that use reference variables tend to run a bit slower. I'm making sure to close the reference each time, but that doesn't seem to make any difference. My question is, what are the recommended/best programming techniques to use for such programs? My main concerns are: clean, easy to read, reusable code, updated indicator values displayed on the front panel, and fast execution times. I would like to avoid opening/closing front panels of subvi's as this can get confusing for the end user.

T hanks for the help!

[RavensFan]

I am going to assume what you mean by "reference variables" is that you are using references to controls in you main VI and using the value property node to update them.

Using property nodes is the slowest of all because a switch to the UI thread is required.  Local variables are faster, direct wiring to a terminal is the fastest yet.  Of course that won't help you for communication between two VI's.

If you have a portion of your main vi that runs even though another portion may be help up by the subVI, you could try using a global variable to pass the data.  Or a LabVIEW2 style functional global.  Or have data passed by way of a queue or notifier to the main VI and let the main VI update the indicator by way of the terminal node.

[Ben]

No I'm not following you around Ravens Fan. It just seems that you and I are interested in the same topics!

Adding to the previous...

1) Reduce the number swaps to the UI thread by only updating indicators if they change. Dont blindly write the same value over and over.

2) Figure out which part of the screen updates are reallt hammering your CPU. Usually something with a lot of data, chart graph table, etc.

3) Prior to screen updates set "deferFPUpdat" = F (to defer screen updates) aplly the screen update then set the defer FP update back to true to allow the screen to update.

4) Reduce how often screens are being updated.

Ben