TS9454 - Are Global Variables Truely Evil?

[crossrulz]

An honest conversation about the usage of Global Variables in LabVIEW including why they are often called "evil", proper usage of them, and alternatives.

[Ben]

http://forums.ni.com/t5/LabVIEW/what-would-cause-one-read-of-a-global-be-slower-than-another/m-p/343...

Nice presentation Tim.

Thank you for the mention when you spoke of Action Engines.

Another issue with Global variables is the impact on performance when we use many of the same Global. In the thread I linked above, I questioned why would one read ofa global be slower than another and I do not think I ever got a good answer. In that case I was using a global for a stop flag to stop about 250 TImed Loops and the Global use introduced "finished Late" situations.

The problem was solved by replacing all of the global reads with a simple Action Engine.

I am mentioning that situation here to let everyone know that there is a potential that multiple global reads can impact performnace.

Thank you!

Ben

[crossrulz]

Curious about the many readers.  I will have to play around with that when I find a little time.  My gut feeling is that your issue was resolved somewhere along the last 10 years.  I am not saying you are wrong, just that it does not feel right.

[Ben]

I hope you are right Tim.

It was the the one time that I "gave globals a chance" and the rest is history.

If you are going to ry and recrate that situation, I was using hardware timed loops so the testing may not be valid without using the hardware Timed Loops.

Aside from this one point and my old song about "but those that follow you may not have read your presentation" I agree with all of the other points you made.

Thank you again for standing up and working to make LabVIEW great.

Ben

[TimVargo]

Just thinking out loud in general about global variables, and without regard to hardware timed loops.  Remember that LV global variables are backed by a file.  Won't every write and read operation of a global then result in a blocking OS call to write/read that file?  This would make every global read highly non-deterministic, and so could explain why one read operation might be slower than another.  Yes, the OS and disk itself are likely caching that data; but this is irrelevant because the OS call itself will still block, and will therefore still be very non-deterministic whether the data is retrieved from cache or a true disk read must take place.

Ben's Action Engine solved this for reads, because the global variable is now cached in a LV Shift Register, guaranteeing that no OS call will be needed to access the value. WRITING to the global, however, even if within the Action Engine, would still require an OS call.

Does this make sense, or am I just rambling nonsense?

[altenbach]

TimVargo wrote:

                       

Remember that LV global variables are backed by a file.  Won't every write and read operation of a global then result in a blocking OS call to write/read that file?

                   

I am sure the globals are loaded into memory, there is no file IO involved during the run.