Array to Array Copy LV Primitive?

[Belzar]

I was wondering why LV does not have a primitive that does copies between arrays like the attached example.

Basically it is the function of coupling array subset with replace array subset.  My thinking is that it saves memory

by preventing the creation of the array subset intermediate value from the source array.

Please see attached.

Maybe there are optimizations under the hood for this...

Thanks

[Jarrod_S.]

LabVIEW doesn't always have to allocate new space for array subsets. They are actually slightly different objects than regular arrays. If you aren't modifying the original data source that the array subset comes from any time soon (and that's a relative thing to say), and you don't modify the subset data before inserting into Destination Array, then LabVIEW can pass in the array subset to the Replace Array Subset without making an intermediate copy.

You can verify this if you have the Profiler tools. Go to Tools >> Profile >> Show Buffer Allocations and notice that there is no dot anywhere on the array subset wire.

Message Edited by Jarrod S. on 03-29-2007 03:23 PM

Message Edited by Jarrod S. on 03-29-2007 03:24 PM

[Jarrod_S.]

Message Edited by Jarrod S. on 03-29-2007 03:26 PM

[Tomi_Maila]

Why does modifying of an array subset require LV to make full copy? I think is lack of optimization in LV compiler 😉

[Belzar]

Thanks.  That is helpful.  I forgot about the Profile menu... In my app, the source array is wired like this and I get the cursed dots.  A primitive would prevent this...

Message Edited by Belzar on 03-29-2007 04:18 PM

[altenbach]

Of course you could combine the two methods. 😉

Message Edited by altenbach on 03-29-2007 06:22 PM

[Belzar]

The For loop solution makes things worse.  You get copies of the destination and source arrays as well as smaller copies for building the arrays.  I'm still seeing the beauty of another array primitive - basically a mem copy for those so C inclined.

Message Edited by Belzar on 03-30-2007 01:54 AM

[altenbach]

So you worry about allocating memory for building a few tiny arrays with two elements each? 😮 How big are your other arrays and subsets comparatively?

[Norbert_B]

Well, Altenbach,

i think its quite good if someone is not only using something, but asks "How does this work? How can i improve the usage of this?"
Nevertheless, since this thread is not the only one of Belzar regarding allocation, i want to make sure:
a) LabVIEW wants to take away the issue of allocating/deallocating memory from the developer since you can mess up things very easily. On the other hand, since you cannot directly reuse/allocate/deallocate memory, you have to live with what LV provides.
b) Even in LV, you can waste lots of memory by using bad programming styles. It is ok, if not neccessary, to ask what creates new buffers and what uses old ones.

But as far as i have seen, Belzar is a bit of "small minded" here (no offense). As a rule i want to tell you: memory allocations shouldn't affect your application in a bad way if you make sure that the allocs are not too big and esp. do not take place in a loop. But even there, small allocs dont have too much impact as long as they are not infinite; allocs which have to be prevented are of the kind shown in my screenshot (sadly, the dot is located at the shiftregister, not at the "build array").

hope this helps,
Norbert

[Belzar]

Forgive me for using the word "memory" in my earlier post.  Time is what I'm really concerned about.  altenbach, you'll notice both the source and destination arrays were copied.  That could be a huge performance impact.  Yes, a two element array copy is no biggie.

Norbert, caring about two full array copies is not being small minded...go back up and look where the dots are in my earlier post.

Right now I'm working around this issue, but thought future versions of LV might be improved with a better primitive.

And Norbert, you are correct that LV removes many hassles by doing memory alloc for you.  In this case, it is not helping but harming overall performance.