LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Global Variables Are Better than Functional Globals - So There! :-)

Solved!
Go to solution

@richjoh wrote:

Uhhh? did you say faster, what line impies that... cus I read this from the link you provide.

 

"Status: Declined

A quick conversion tool would imply that switching from global variables to functional global variables are better (e.g. reduce code overhead, race conditions) when they are not specifically.

"

 

appear to me not better maybe specifically.... Try something whenever possible, write code using your described globals methods, see if it runs faster, multithreads, multiprocess faster and your code debugs faster.


 

See the footnote in the first reply from Aristos Queue

* actually, the functional global will perform worse. It has higher overhead in that case.
=====================
LabVIEW 2012


0 Kudos
Message 21 of 51
(995 Views)

@richjoh: Thanks for the clarification. Then I just hope these links will provide some value for the occasional reader.

 

@Steve: As far as I know, globals do not need the UI thread (as long as they are not opened). I think there was a thread where AQ did explain the inner workings on LAVA, where he did also state that globals do require some buffer less than whatever, hence they'd be faster.

Your lastest post does prove my predictions, however I made the assumtion:

One might ask, why the global is put outside the foor loop. But this is intentional for two reasons:

  • The idea of a 'global' (including FGV and AE) is to access it at different sections of the code.
  • Having it outside, I would benchmark the performance of the wire and not the global.

It's sad that this idea is declined now. I'd advice to vote for it because the very reasons I explained in my previous posts.

 

Felix

Message 22 of 51
(987 Views)

@f. Schubert wrote:

 

It's sad that this idea is declined now. I'd advice to vote for it because the very reasons I explained in my previous posts.

 

Felix


I might try to implement that via scripting and the right-click framework. But I don't have any experience with either.

=====================
LabVIEW 2012


Message 23 of 51
(982 Views)

Scripting is easy. Just make a template for a Get/Set AE. Then just replace (use one of the replace methods) the data-control/indicator of the AE template with the one of the global.

 

I was thinking the same (do it on our own). I could get that part tomorrow coded in 7.1, so working for everyone. Integration into RCF is up to you unless someone else is volunteering. Please let's do this on LAVA so we can put it under BSD license (or other if you prefer). Give me a PM if you'd like assistance either using NI account or LAVA (Blackpearl).

 

Felix

0 Kudos
Message 24 of 51
(972 Views)

SteveChandler, oh you mean this quote "

* actually, the functional global will perform worse. It has higher overhead in that case.

". No wonder I missed it, its so small. hey ever ask Aristos Queue to prove his statement. I never take someone's word it must be conherent at least in my mind.

 

F Shubert, I think you might have missed the point though on my original post. SteveChandler code uses sequence structure and error cluster to attempt to replace his FG. OK OK. Not sure your code help this discussion, no need to digress off topic, talking about your code...and not....SteveChandler issue.

 

Again repeat, in case of no error cluster wired to sequence, using lots of sequence structures on the same BD and they don't run at the same time (the OS/cpu determines what sequence structure get run first). Any LV veteran will tell you use sequence structure only when needed...but first understand what they are used for and functionality... from the NI LV sequence structure help 

 

"To avoid overusing Flat Sequence structures, attempt to control the data flow of your VI by establishing data dependency or using flow-through parameters.

"

So two or more sequence structure without a wire to or from there is no data flow. When a sequence runs the rest of your block diagram halts till the sequence finishes Smiley Happy Write code this way (globals inside a sequence) well is no longer LV.

0 Kudos
Message 25 of 51
(959 Views)

@richjoh wrote:

SteveChandler, oh you mean this quote "

* actually, the functional global will perform worse. It has higher overhead in that case.

". No wonder I missed it, its so small. hey ever ask Aristos Queue to prove his statement. I never take someone's word it must be conherent at least in my mind.

 


I tend to not take peoples word for anything. But there are certain people that include Stephen Mercer that when they say something I do take their word for it. But he did qualify it by saying "in that case".

=====================
LabVIEW 2012


0 Kudos
Message 26 of 51
(968 Views)

@richjoh wrote:

"

When a sequence runs the rest of your block diagram halts till the sequence finishes Smiley Happy


Maybe I'm not clear on what you are trying to say.

 

But the sequence structure does not cause "the rest of your block diagram" to halt until the sequence finishes.  If there is no data dependency or anything else causing a forced order of execution, the sequence structure will run in parallel with any non-dependent code pieces.

0 Kudos
Message 27 of 51
(967 Views)

@richjoh wrote:

 

Again repeat, in case of no error cluster wired to sequence, using lots of sequence structures on the same BD and they don't run at the same time (the OS/cpu determines what sequence structure get run first). Any LV veteran will tell you use sequence structure only when needed...but first understand what they are used for and functionality... from the NI LV sequence structure help 

 


The point of the example was to show that global variables in and of themselves do not cause race conditions. Thanks for the link to the documentation but I think I understand sequence structures pretty well Smiley Happy. The example I used is one where you really do need them. 

=====================
LabVIEW 2012


0 Kudos
Message 28 of 51
(949 Views)

Steve,

 

The issue of race conditions is of but one.  Everything you proposed can be done, obviously, but Felix's example is far more telling of the inherent issues.  I can't reproduce anything AQ stated where I could get better performance form a Global, but I am sure there is a case to be made that it's tru in some conditions.

 

  1. Yes, race conditions can be fixed by sequence structures.  But dropping sequence structures everywhere in your code to enforce this just leads to sloppy and ugly code.  As you mentioned, you can wrap the Global in another VI so you don't have to do this all the time, but then you've just made a functional global out of a global.  If you take Felix's code and change his functional global to use the global instead of shoft registers, his code takes a major hit as the data is copied (a couple of ms to >5000ms).  As Felix explained, there is a lot of benefit in keeping data on the wire.  It doesn't always work out.  If I add an array indicator that outputs the array as well, I add a performance hit, but I can add that to only occur when I need it instead of all the time.  For simple numbers, you may never really see it, but the performance issues are there.
  2. The overall added functionality cannot be understated.  The ability to not update a global on an incoming error, adding the ability to lock access by using a semaphore, indexing the array inside your subVI instead of every time you want one element (Felix's code demonstrates how much speed you can pick up by doing this), etc., etc.  Again, yes, you can do all this with a Global as well, but you are either doing a lot of work on your block diagram, or you are making a functional global using a global variable.
  3. Scalability/the "oh crap" factor.  In a lot of cases, globals are probably fine.  It is certainly faster to go through and drop new globals than try to create new functional globals.  Any lost performance will be minimal and unnoticeable.  There will not be any race conditions.  There is no need to lock globals.  Then you find out that you do indeed have an issue and you need to implement something a bit more robust.  Now you are spending time trying to figure out what is going on and more time going back updating your globals to functional globals to address the issue.  Sometimes it's better to just do it "right" from the beginning.
  4. Debug.  Since I haven't used a global in years, I don't know if LabVIEW (I couldn't find it) has the ability to do a watch on a global, other than opening the panel and looking at it.  But since I can't put a probe on a control, I can't automatically have my code break on a certian condition.  Using the functional does allow me to get a higher level of debugging and tracing.

Of all the reasons to not use globals, the race condition reason is probably one of the lowest on my list.  Even with eorr clusters or sequence structures, etc., you can still easily get into race conditions.  the overly simple example you provided is not the way the real world works.  Obviously, of someone presented your example, we would say connect the wires and drop the globals.  Typicallly, our race conditions come from two parallel tasks and connecting them via error wires to force order of execution is not an option.

Message 29 of 51
(929 Views)

@Matthew Kelton wrote:

Steve,

 

Scalability/the "oh crap" factor.  In a lot of cases, globals are probably fine.  It is certainly faster to go through and drop new globals than try to create new functional globals.  Any lost performance will be minimal and unnoticeable.  There will not be any race conditions.  There is no need to lock globals.  Then you find out that you do indeed have an issue and you need to implement something a bit more robust.  Now you are spending time trying to figure out what is going on and more time going back updating your globals to functional globals to address the issue.  Sometimes it's better to just do it "right" from the beginning.


Preaching to the choir. I inherited a very large application that uses global variables everywhere. I converted them all to functional globals and then added a Generate User-Defined Trace Event to the vi to do some debugging. This post was inspired by Aristos's response to an idea I posted on the idea exchange that would have made this easier for me. The idea was declined the very next day. I think this is a record. Was this really the worst idea ever posted?  Smiley Very Happy

 

One thing I constantly hear on the forums is that globals and locals cause race conditions. This post was simply to show that they do not - it is how they are used. Oh and I had to figure out how to create a global variable for my example on the idea exchange since I had never used one. Smiley Happy

 

=====================
LabVIEW 2012


0 Kudos
Message 30 of 51
(919 Views)