Inplace Array Size

[spatry]

I've been working with large arrays, and I've found that wire branches are killing my performance. In order to alleviate this I've scattered inplace structures all over, however, the only way I have to access the array size without incurring a copy of the array is to track it separately, and access that size property, this seems pretty wasteful. 

I can think of two ways to implement this. The first is to add an array size block to the inplace element structure, this would be awkward to use. So, I suggest the the array size node be made inplace, as mocked up below.

Thanks

[AristosQueue (NI)]

Why do you have to copy the whole array? Just because you fork a wire doesn't mean a data copy is made. LabVIEW compiler is smart about when it needs to make copies and when it doesn't. And it won't in this case. (If you're seeing a data copy from this kind of fork, that should be a CAR, but given just how much of LabVIEW would shatter performance-wise if that part of the compiler were broken, I have extreme doubts about your claim... not saying you're wrong, but we'll need evidence.)

[RavensFan]

Do you know for a fact that the array is being copied?  Did you use Show Buffer Allocations?

When I recreated your image, I saw only 1 buffer for the array.

I like your idea of a "pass through" function for the array, but I don't think it is needed.

[AristosQueue (NI)]

> I like your idea of a "pass through" function for the array

I don't. Outputs for by-value types that are not modified by the function create more usability problems than they solve. In my observation, they all end up doing what people do with the error cluster -- needlessly serializing operations that have no need to be serial and just burning performance (if I could go back to the dawn of LV and fix the conventions, any function that does not itself produce an error would only be allowed to have an Error In, but that's part of a much broader discussion... end tangent.). Let the LV compiler do its job.

The original post was fixing problems by using the Inplace Element Structure. That means the problem was in the copying of the elements in the array to modify them, not in the copying of the array itself to two different writers. And if you're really forking an array to two different writers, you *have* to have a data copy.

So as far as I am concerned, this node wouldn't help the original issue, and it would just be another "hey, I'll just string this data through here" temptation for those who don't really grasp what that does to the dataflow.

[spatry]

I haven't verified that it copies, but the semantics of a wire branch are that it copies.  And I had many other wire branches causing my code to run slowly. So, I went on a 'remove all the branches' binge to be sure I wasn't making unneeded copies.

I just coded up similar program and checked the buffer allocations to be sure, and you are correct Aristos, it does not allocate, sorry for my paronoia.

[AristosQueue (NI)]

> but the semantics of a wire branch are that it copies.

Nope. The semantics of a wire branch are that the data from the source is available for all downstream operations. The mechanics of *how* that data is available is entirely a private choice of the LV compiler.

Your issue was coming from forking wires to multiple write operations, where making a copy is required. You've resolved those with the IPE structure.

[altenbach]

The "inplacer" was introduced in LabVIEW 1.1 😄 I am sure the algorithm is highly polished by now ....

[Darin.K]

>The "inplacer" was introduced in LabVIEW 1.1 I am sure the algorithm is highly polished by now ....

The Font pulldown menu was introduced around then as well, how polished is that? 

[AristosQueue (NI)]

> The Font pulldown menu was introduced around then as well, how polished is that? 

Very. You haven't seen it do anything it wasn't designed to do in a long time.

[altenbach]

> Very. You haven't seen it do anything it wasn't designed to do in a long time.

Sometimes I wish it would do less. "Shadow" and "Outline" font styles are pretty obsolete. 😄

[A-T-R]

---

@AristosQueue (NI) wrote:

In my observation, they all end up doing what people do with the error cluster -- needlessly serializing operations that have no need to be serial and just burning performance

---

This is rather OFF TOPIC....but you are so right!