Reverse 1D Array and insert into array are not compatibles?

[tst]

---

battler. wrote:

Before the existence of tools such as the performance monitor and I was trying to optimise my code I gained the idea (from the NI documentation) that reading/writing to the Property node Value was more efficient than using a Local Variable.  It is something which has stuck with me for a long while now.

---

I don't know how this idea became so prevalent, but it's completely wrong. The Value property is NOT more efficient than a local variable. Both will create a copy of the data (ONLY the data, not the "variable", whatever that is) for the wire coming out of them, but the property has an additional penalty which the local does not.

[battler.]

A few years back there wasthis whole thing about LV Memory Management. 

http://digital.ni.com/public.nsf/allkb/771AC793114A5CB986256CAB00079F57 

This was a well-known statement:

"Limit the use of global and local variables. Using global and local variables causes LabVIEW to generate copies of the data in the variables."
 

There was also this:

"Property Nodes cause the front panel of a subVI to remain in memory, which increases memory use. Therefore, if the front panel of a subVI is not displayed, do not leave unused Property Nodes on the subVI."

But that didn't make any sense; "..do not leave unused Property Nodes on the subVI".  Furthermore the doc made no comparison between using the local variable and the property node.

It was stated that property nodes were better for "memory management" (i.e. there were no duplicates made of the data - hence less memory was used).  I could keep searching for more evidence but I think I'd better take a look at some of your benchmarking results..
 

[tst]

---

battler. wrote:

"Limit the use of global and local variables. Using global and local variables causes LabVIEW to generate copies of the data in the variables."

---

Yes, and the same is true of the Value property, even if it's not mentioned in that document. In any case, it's important to note that one thing your previous link pointed out is correct - this is only really an issue if your data is large. The Value property is also a problem in that it can force a thread switch. 

---

"...Therefore, if the front panel of a subVI is not displayed, do not leave unused Property Nodes on the subVI."

---

Loading the FP of a VI takes up memory, so you don't want it to be loaded if you don't need the FP. This sentence was phrased badly and what it should say is something like "If you're not going to display the FP of the SubVI, do not leave...".

By default, the FP is removed from every VI which isn't configured to have its FP displayed when you build an executable. As the document said, "Property Nodes cause the front panel of a subVI to remain in memory", and I actually do use this trick when I want VIs to keep their FP even if their FP is not explicitly configured to be displayed - I create a property node for one of the controls in the VI, which forces the FP to be kept.

---

It was stated that property nodes were better for "memory management"

---

I don't see this statement anywhere.