LabVIEW Memory Management VI question, a special request to you

[*3d0g]

"Since all the Call Library Nodes are set to run in the UI thread (dark yellow background) they can't possibly run in parallel so there is no need to create a separate array copy for each of them."

I thought the way I forced dataflow with the error path did that.  Each CLFN operation happens sequentially; I forced it that way. No?

Yes, I botched the DVR, but what I was trying to do is reuse the same array space, over and over.  I'm still working on the "separate array copy" part of what you said.

[*3d0g]

altenbach:

This was a good post:

"

Just a few quick comments:

• Yes, your DVR does absolutely nothing. Maybe the compiler is even smart enough to eliminate that entire hairball during optimization, because it is never really used.
• You can eliminate ALL your value properties by setting "Vi properties .. execution .. clear indicators when called". (If you want to set them programmatically, you would use local variables, not value properties!)

"

Hairball. I love it. ...made me laugh!  So true!

Plus the local variable tip... Thanks!  And the Vi properties setting to clear indicators when vi called... Interesting!  Again, thanks for the tip!

[UliB]

---

@*3d0g wrote:

[...] (The bonus is you caught on to the fact that I'm unfamiliar with the workings of the software behind this forum. [...]

---

When replying to a message you can use the quote button. It names the author, copies the message and gives a visual indentation to the quoted message.

[*3d0g]

---

@UliB wrote:

---

@*3d0g wrote:

[...] (The bonus is you caught on to the fact that I'm unfamiliar with the workings of the software behind this forum. [...]

---

When replying to a message you can use the quote button. It names the author, copies the message and gives a visual indentation to the quoted message.

---

this is a test. disregard please.

[Intaris]

---

@*3d0g wrote:

What's a knot, as you used the term?

---

You can think of every branch of an array wire of (potentially) causing a memory copy. Unless the code on one end of the branch is guaranteed to NOT alter the buffer (in which case the compiler simply executes the code in series, with the modifying portion going last), a copy will likely be the result. Note that the "buffer allocations" display in the LabVIEW IDE shows what it sees as all "potential" buffer allocations. Some of these may depend on run.time data like indexing an array out of bounds. They may never actually happen.

This is dataflow. It is not an error or a bug, it's a cornerstone of the G programming language which is what we're using LabVIEW to program. Dataflow has its own rules. If you are trying to view LabVIEW through a by reference lens, you will have a very tough time. Learn about Dataflow, why it's a good choice for certain types of applications and then understand why LabVIEW programming is done the way it is. The rules are different than for by-reference based languages.

While not explicitly focussing on dataflow of memory copies, the following link might help you understand more of the fundamental ideas behind the LabVIEW dataflow and by-value model.