What is the benefit of passing variables to Vi's instead of Refs?

[nathand]

---

@Steve Chandler wrote:

There is only one user interface thread. Swapping to it is time consuming. The reason for the swap is that controls are a user interface component so need that thread. There are property nodes that do not require the UI thread such as LVOOP accessors. (Someone correct that if I am wrong)

---

A LVOOP accessor is a call to a VI in disguise, so there's no need to swap threads.  The property node representation just makes it a bit easier for the programmer to see what's happening.

[DFGray]

For the record, local variables (and control terminals) are about 1000 times faster than the Value property node in setting values.  The reason is that local variables do not require a switch to the UI thread.  Instead, they write to the transfer buffer of the control.  When the front panel is updated (at about 60Hz), all transfer buffer values which have changed are used to update the controls.  The Value property, on the other hand, is a synchronous operation that does not return until the control on the front panel is fully updated.  You can mitigate this somewhat by judicious use of the Panel property Defer Panel Updates if you have multiple controls to set, but you will still get the synchronous behavior at some point.

[Ben]

---

@nathand wrote:

---

@eximo wrote:

I had been led to believe references were like pointers so they would use less memory because there was no copying, hence less time would be taken up.  Now i'm trying to reconcile my fractured understanding of memory and timing in regards to references, property nodes, and local variables.   

---

A reference is not like a pointer.  A reference is to an object on the front panel, NOT to a space in memory.  For someone accustomed to managing memory, this can  be a hard concept.  When you pass data on a wire into a subVI, you don't really know whether it's being passed by value or by reference, and even better, you don't have to worry about it.  If it's necessary to make a copy of the data (for example, because the subVI modifies the data and the unmodified values are used somewhere else later), then LabVIEW will make a copy.  If the compiler determines that no copy is necessary, then the subVI gets a reference to the original data.  There are tricks you can use to minimize data copies, but references are not one of them.

---

Its time for me to link up the "Clear as Mud" thread again.

It is possible to benchmark these perfomance differences but it could be hard to see a differnce for the smaller data  sets.

Ben

[eximo]

That bench mark test showed that the local variables are about 15 times faster, not 1000 times.  Still 15x is pretty pricey when you multiply the time by 10's or 1000's of iterations

[eximo]

I'm also not entirely trusting that LabVIEW "knows best" when it comes to making a copy or reusing the same memory location.  

[Ben]

---

@eximo wrote:

I'm also not entirely trusting that LabVIEW "knows best" when it comes to making a copy or reusing the same memory location.  

---

Nor do I. It would be like trusting your surf board to "know best".

LV will make decisions based on your code and try to minimize buffers but if your code says "I want three copies of this data" (could happen if you branch a wire into 3 paths) then LV will do what you tell it.

Use Profile >>> Show buffer allocations to see what LV thinks is required re:buffers and then it is up to us to refine what we tell LV.

Ben

[majoris]

Worry about performance when you have to. While it might not always get everything right, Labview generally does a good job. When your application grinds to a halt or starts consuming ludicrous amounts of memory, break out the profiling tools and optimize as needed. Of course, if you know you're going to be passing around a large amount of data and want to control the copies explicitly, consider using the data value reference.

That is all!

[Ben]

---

@majoris wrote:

Worry about performance when you have to. While it might not always get everything right, Labview generally does a good job. When your application grinds to a halt or starts consuming ludicrous amounts of memory, break out the profiling tools and optimize as needed. Of course, if you know you're going to be passing around a large amount of data and want to control the copies explicitly, consider using the data value reference.

That is all!

---

About 11 years ago the owner of my company asked the question

"We always get the code working but why do so many customers complain about performance?"

The answer was that the developers were only worrying about performance after some complained.

Fast forward... all developers have since been replaced and they have been subjected to my anal-retentive nature.

Think about performance at design time, ID where the loads will be and "worry about the performance in the large data set vis" while developing and watch the CPU uses like a hawk while doing unit testing.

Ben

[Ben]

---

@majoris wrote:

Worry about performance when you have to. While it might not always get everything right, Labview generally does a good job. When your application grinds to a halt or starts consuming ludicrous amounts of memory, break out the profiling tools and optimize as needed. Of course, if you know you're going to be passing around a large amount of data and want to control the copies explicitly, consider using the data value reference.

That is all!

---

About 11 years ago the owner of my company asked the question

"We always get the code working but why do so many customers complain about performance?"

The answer was that the developers were only worrying about performance after some complained.

Fast forward... all developers have since been replaced and they have been subjected to my anal-retentive nature.

Think about performance at design time, ID where the loads will be and "worry about the performance in the large data set vis" while developing and watch the CPU uses like a hawk while doing unit testing.

Ben

[JÞB]

---

@Ben wrote:

---

About 11 years ago the owner of my company asked the question

"We always get the code working but why do so many customers complain about performance?"

The answer was that the developers were only worrying about performance after some complained.

Fast forward... all developers have since been replaced and they have been subjected to my anal-retentive nature.

Think about performance at design time, ID where the loads will be and "worry about the performance in the large data set vis" while developing and watch the CPU uses like a hawk while doing unit testing.

Ben

---

A point worth making twice!

Eximo-

I just shook the 8-ball and it answered "Yes- he's definately a text programmer converting to LabVIEW- Maybe"

(Using the word "Variable" in a LabVIEW context is a dead give-away.  Really, there are no "variables" in LabVIEW only buffers The distinction is fine but .... well, thats a differnt topic)

Passing data in LabVIEW can be done in many ways:

"VI Server referances":  What I believe you are mistakenly refering to as "Referances" transfer essentially a memory location that holds a LabVIEW Object (Application instance, VI, Panel, Decoration, Control/Indicator, Block Diagram, Structure.....)  the caller of this VI server reference can access every property of the object and modify them under some constraints. Additionally, the VI Server referance may be used to invoke a method on the object
  See Magician.vi in post 23 of this thread for an excellant example of this.  and just how powerful a VI server reference can be! 

So a VI Server reference may not be the best way to operate on an object if you only need the value property

Wires- pass the value property of an object between nodes (Well actually they inform the nodes where the buffer is)

Terminals/Locals- as noted earlier pass values to-from FP object transfer buffers.

Queues/ Notifiers- pass locations of buffers that must be shared between accessors

Data Value References: Flipping black magic and voodoo (If I even attempted to explain them I would be corrected I'm Sure)

Buffers, Nodes, Wires, Objects, Properties and Methods If we had to think about them all the time and understand everything LabVIEW would be just another language we would need a computer science degree to use.  LabVIEW does abstract all of that away in the IDE and we can sling wires and let LabVIEW DO! 

ON THE OTHER HAND! writing LabVIEW code that is optomized for performance requires understanding some of the abstract LabVIEW interactions and the IDE even provides tools to expose them.  (And some rules of thumb in the LabVIEW Help file to get you on the right track)

Excellent Question!