LabVIEW "myths"

[GregFreeman]

There are some LabVIEW myths out there, which are really just misunderstandings. I would like to put a couple on "paper" that really bother me. To vent, so to speak. Please, feel free to add to the list. Here are two, to start:

Shift registers take time to pass data from one side of the loop to the other.

Using multiple levels of VIs (subVIs within subVIs) slows down your code.

[PaulG.]

---

for(imstuck) wrote:

... Shift registers take time to pass data from one side of the loop to the other.

---

And the wider the loop the longer the data takes to go from one side to the other!

[GregFreeman]

---

PaulG. wrote:

---

for(imstuck) wrote:

... Shift registers take time to pass data from one side of the loop to the other.

---

And the wider the loop the longer the data takes to go from one side to the other!

---

BAHAHA, I wish I could give multiple kudos. One will have to do.

Message Edited by for(imstuck) on 02-26-2010 12:02 PM

[smercurio_fc]

---

PaulG. wrote:

---

for(imstuck) wrote:

... Shift registers take time to pass data from one side of the loop to the other.

---

And the wider the loop the longer the data takes to go from one side to the other!

---

I thought it had to do with trying to stuff a whole lot of data into an itty bitty thin wire. 

[DianeS]

But often the wire gets thicker when you add more data...2D array wire is bigger than 1D array wire, 1D array wire is bigger than single number wire...

That doesn't apply to clusters, though...a cluster wire is the same size regardless of how many things you have in your cluster.

Hmm.

[altenbach]

---

for(imstuck) wrote:

Using multiple levels of VIs (subVIs within subVIs) slows down your code.

---

This is not a myth, but a fact. Calling a subVI always involves some overhead, so, everything else being equal, flat code is faster than a hierarchy. You need to find the balance between code modularity and efficiency. Proper code is typically not CPU limited so modular programming is still highly preferred. The speed also slows down if any of the subVIs have the front panel open. If the subVIs are not re-entrant, you can even accidentally force sequential execution of calculations that could be done in parallel on a multicore machine.

This goes along the myth that buying a faster computer will solve all your performance problems. This is never true. If it does not run well on the current machine, something is wrong with the code (with very few exceptions). Simply throwing a faster computer at it just means that it will do even more unnecessary stuff per unit time. Differences in hardware can maybe give you a factor of two. Peanuts! Rewriting the code for proper in-placeness and pacing can give you several orders of magnitude. 😉 

---

for(imstuck) wrote: 

Shift registers take time to pass data from one side of the loop to the other.

---

 I guess you remembered this discussion. 😄

Some other myths: 

Formula nodes are slow. (They are NOT!)

LabVIEW is not a compiled language (definitely wrong).

[RavensFan]

---

PaulG. wrote:

---

for(imstuck) wrote:

... Shift registers take time to pass data from one side of the loop to the other.

---

And the wider the loop the longer the data takes to go from one side to the other!

---

Actually, it does take longer if you have highlight execution turned on!

[GregFreeman]

---

altenbach wrote:

---

for(imstuck) wrote:

Using multiple levels of VIs (subVIs within subVIs) slows down your code.

---

This is not a myth, but a fact. Calling a subVI always involves some overhead, so, everything else being equal, flat code is faster than a hierarchy. You need to find the balance between code modularity and efficiency. Proper code is typically not CPU limited so modular programming is still highly preferred. The speed also slows down if any of the subVIs have the front panel open. If the subVIs are not re-entrant, you can even accidentally force sequential execution of calculations that could be done in parallel on a multicore machine.

This goes along the myth that buying a faster computer will solve all your performance problems. This is never true. If it does not run well on the current machine, something is wrong with the code (with very few exceptions). Simply throwing a faster computer at it just means that it will do even more unnecessary stuff per unit time. Differences in hardware can maybe give you a factor of two. Peanuts! Rewriting the code for proper in-placeness and pacing can give you several orders of magnitude. 😉 

---

for(imstuck) wrote: 

Shift registers take time to pass data from one side of the loop to the other.

---

 I guess you remembered this discussion. 😄

Some other myths: 

Formula nodes are slow. (They are NOT!)

LabVIEW is not a compiled language (definitely wrong).

---

1. Excuse me on that first comment. I must have misunderstood that at NI dev day when they talked about it. However, now I know :). I had heard it around the office and was never really sure whether or not to believe it

2. That discussion will haunt me forever...

[Dennis_Knutson]

---

altenbach wrote:

---

for(imstuck) wrote:

Using multiple levels of VIs (subVIs within subVIs) slows down your code.

---

This is not a myth, but a fact. Calling a subVI always involves some overhead, so, everything else being equal, flat code is faster than a hierarchy. You need to find the balance between code modularity and efficiency. Proper code is typically not CPU limited so modular programming is still highly preferred. The speed also slows down if any of the subVIs have the front panel open. If the subVIs are not re-entrant, you can even accidentally force sequential execution of calculations that could be done in parallel on a multicore machine.

This goes along the myth that buying a faster computer will solve all your performance problems. This is never true. If it does not run well on the current machine, something is wrong with the code (with very few exceptions). Simply throwing a faster computer at it just means that it will do even more unnecessary stuff per unit time. Differences in hardware can maybe give you a factor of two. Peanuts! Rewriting the code for proper in-placeness and pacing can give you several orders of magnitude. 😉 

---

for(imstuck) wrote: 

Shift registers take time to pass data from one side of the loop to the other.

---

 I guess you remembered this discussion. 😄

Some other myths: 

Formula nodes are slow. (They are NOT!)

LabVIEW is not a compiled language (definitely wrong).

---

The myth of the faster computer is similar to fixing memory leaks by adding more RAM to the pc.

[altenbach]

---

@Dennis Knutson wrote:
The myth of the faster computer is similar to fixing memory leaks by adding more RAM to the pc.

---

 ... or fixing a roof leak by buying a larger bucket 😄