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

[Matthew_Kelton]

I went ahead and updated Felix's original code to use a single DBL instead of an array and did 10,000,000 writes and 10,000,000 reads.  And, indeed I did see about a 3x performance hit by using functional globals instead of globals.  So, in this more simplistic case, it would have been better to use a global from purely from a speed standpoint.  But again, on 10,000,000 cycles, we're talking about 1s to execute vs. 3 secs to execute.  For most applications, the time difference would be indistinguishable, since the benchmark is fairly non-real world.

I'll stick with the functional globals.  I disagree with AQ's reasoning behind declining it.  I agree with Raven's reasoning that I think there are better things to use development time on, though.

[richjoh]

---

richjoh wrote:

"

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

Ravens Fan wrote:

"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."

---

Ravens Fan your absolutely correct, thanks for clearing that up. What I should have said is two sequence structures on the BD do not run at the same time (like wires). I can best display this by a simple VI attached. Just run it with hightlight turned on. You will see the three sequence run in order 2,3,4 or 4,3,2 or 3,2.4...etc etc but not all together (like wires appear to do when hightlight is on.

[RavensFan]

---

@richjoh wrote:

Ravens Fan your absolutely correct, thanks for clearing that up. What I should have said is two sequence structures on the BD do not run at the same time (like wires). I can best display this by a simple VI attached. Just run it with hightlight turned on. You will see the three sequence run in order 2,3,4 or 4,3,2 or 3,2.4...etc etc but not all together (like wires appear to do when hightlight is on.

---

What you show is not a good example.

First, with highlight execution, it is slowing things down and showing you one thing at a time.  Since each sequence structure has only one thing going on in it, it looks to you like each is doing something not in parallel to the others.  If you actually had more code in there and ran it with highlight execution, you'd see each sequence structure is doing things at the same time.  Do something as simple as put a concatenate in the middle of the string wire.

I don't understand the comment "That's why you need wires" in the VI front panel.  You are saying the parallel sequence structures don't run in parallel, which is untrue, and that you need wires to make them run in parallel.  That is also untrue.  If you had wires between the sequence structures, then you would be forcing them to run in sequence.

[SteveChandler]

It really can be difficult to tell what is happening when. The basic oversimplified rule is that LabVIEW will execute code whenever it feels like with the only restriction being dataflow. That is how I look at it anyway. LabVIEW creates chunks of code and queues them for execution.

Run this with highlight execution and it looks like richjon is right and a sequence structure does block everything else. That seems like a good theory although I can not see any reason for it. But run it without the sequence frames and you see the same thing.

If there is not a dataflow dependency then you really have to understand the compiler pretty well to know what happens when. The Desktop Execution Trace Toolkit can be really helpful.

Run these with highlight execution. They look the same.

[richjoh]

OK, Ravens Fan your right is not a good example because that part of what I said is wrong, your absolutely correct. I am probably thinking about when you add a frame to a flat sequence structure, they garantee sequential execution. I very very seldom need to use a sequence structure and when I do its with an error cluster (I stopped using Globals all together).

Look in any event, I see no need to promote use of Globals. The paste below is out of the LV Help.

"Tip   To help control data flow, you can use error clusters instead. If flow-through parameters are not available and you must use a sequence structure in a VI, consider using a Flat Sequence structure. Refer to the LabVIEW Style Checklist for more tips on when to use sequence structures."

[richjoh]

SteveChandler your (and my) example show identical functionality in each seperated sequence. It may appear to run sequentially that way (hmmm maybe it does in special cases, I'm not 100% sure). As soon a one of them (sequence) is different you see the wire running "parallelism" like. Thats the LV advantage. Adding a frame to a sequence garantees serial operation.

And from the LV help it looks like sequence structure will sequentially use a hardware resource though. (Since I seldom use sequences I wouldn't know).

[SteveChandler]

If you really want to know more about this stuff the following link has some really good information. http://zone.ni.com/devzone/cda/tut/p/id/11472

[Ben · Accepted solution]

I go on vacation for a week and I come back to this?

Dogs and cats living together...

In this thread I swore off Globals once and for all.

Flat out bench-marks on just the global may trick you into thinking they are faster but they simply do not allow working in-place.

Ease of support is another big factor.

Re: call overhead

It is a standard to include "extra" terminals on an icon connector but I have benchmarked the "extra terminals" and the call over-head scales with the number of extra copies.

Data copies

and the most frustrating part ofa global is, you can not do a ctrl-e to fix it.

Ben

[JÞB]

---

@richjoh wrote:

---

@richjoh wrote:

"

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

@Ravens Fan wrote:

"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."

---

Ravens Fan your absolutely correct, thanks for clearing that up. What I should have said is two sequence structures on the BD do not run at the same time (like wires). I can best display this by a simple VI attached. Just run it with hightlight turned on. You will see the three sequence run in order 2,3,4 or 4,3,2 or 3,2.4...etc etc but not all together (like wires appear to do when hightlight is on.

---

Its not the structures-  the PROMPTS run in the UI thread and there is 1 ui thread

[richjoh]

Read Ben's link, UI thread appears to not be a factor (its unclear) from NI folks. Anyhow yes UI thread is slooooow compare to wire run.

Another point in Ben's thread the LV compiler is not a steady project, its gets enhanced. I took LV2010SP1 ran the BD below (hightlight on) and it appears each sequence runs sequentially. This is different action when using LV 8.2.1 (my post above) when I tried similiar action. Version 8.2.1 appeared run sequentially only when the sequences are identical, mentioned by SteveChandler and myself.

Not need to bring up UI thread.