Array to Array Copy LV Primitive?

[altenbach]

---

@Belzar wrote:
 altenbach, you'll notice both the source and destination arrays were copied. 

---

Well, that is no different to all the other posted examples. I thought we were talking exclusively about the memory copy of the subset.

It probably would not be that great if it would reuse the memory of the front panel control.

[Belzar]

It is different in an important way - the whole source and destination arrays are copied and not just the subsets as in previous examples.

[altenbach]

Different to what? Sorry, maybe we are not talking about the same thing. I was comparing to e.g. Jarrod's example from above:

[Belzar]

My bad, I can't see the forest for the trees.  You're right.  I had totally ignored the original source/dest array copies as I looked at the subset copies.  Thanks for looking.

[Norbert_B]

Belzar,

i fear you are running into a general misunderstand of the "display memory allocation" and "copying data"....

First important thing:
User Interface (UI) and dataspace (of the execution) are not the same. Therefore data entered in the UI has to be transferred to the dataspace. This is in fact a copy, yes, BUT the space is already allocated (shown by the allocation dot) in the dataspace. So this is done VERY fast (at least if you are using terminals!) and you can NEVER remove this. This is because BD constants have to be "copied" from the compiled codesegment to the dataspace as well when executed.

Second import thing:
If you take care about good programming styles, all your data needed can be allocated just when you start the application (and each will show a dot!). This will take a short time. But when the application is running, its just like working with variables or references (depends on the usage) in e.g. C.
All these allocations are displayed by the tool.
BUT the tool does NOT differ if the space is allocated ONCE on startup or if it is REallocated during runtime. And you are correct that REallocation takes a lot of time, regardless of size (it is quite linear in fact if the OS does not need to swap and old data has to be copied to the new space....). So you shouldn't bother about the allocs done once. But (there, you are 100% right) you should consider, if the dots are included in loops, moving them out if possible; it could increase performance, both in time and memory.

I dont know which programming language you are familiar with besides of LV, but every language has to create allocs and then work with references to this memory......

hope this helps,
Norbert

[Belzar]

That makes sense.  Using front panel inputs on this example may have confused the overall issue I've been running into.  I created this example for simplicity sake and not to show my exact issue.  I wanted the primitive so that the subset copies don't occur.  The front panel brought up another whole separate topic, which I didn't intend.

I've just spent considerable time going through my entire RT app with "show buffer allocations"  (I've posted about another "find" here) and it is surprising where and why the arrays/clusters are copied.  Sometimes it is not obvious and has to be figured out with trial and error.  (Side note:  Perhaps that is a good feature to add to "show buffer allocations" - why does LV think it needs to copy.  i.e. one array forking out into two inputs, front panel copy, etc.)

My app is very time critical and was initially way out of bed due to such copies as these.

And yes, I agree memory allocation is an issue no matter how or who does it.  I have C/C++/java experience and I am missing the freedom of C.  I'd copy data where I need to if I was doing this in C.  LV copies because it doesn't understand the next layer up which is in my head.  There may be good reasons why copies don't need to be made, but the code doesn't show it.  Yes, C gives you plenty of rope to hang yourself with.  Perhaps LV hides the rope so you find yourself tripping over it 

You've been very helpful and my timing is now looking good...thanks for the original reminder about show buffer allocations.  I was only seeing the timing effect in "execution trace tool" and not the cause via "show buffer allocations".

I'm happy and have my enlightenment for the day.  Thanks to all.

[Jarrod_S.]

Norbert seems much more familiar with the inner workings or LV memory management than I am, but here's a note about your second example of trying to replace two array subsets with subsets of another array. You noted that LabVIEW suddenly shows buffer allocation dots for both subsets in this case where there weren't any for one subset. My guess is that LabVIEW senses it might need both of these array subsets simultaneously, and as such it shouldn't think of them as the same data to avoid a conflict. If you make the replacement steps sequential (such as with Altenbach's loop or the pic below), LabVIEW can figure out not to make a copy of the array subsets.

My procedure is tedious but avoids allocating index arrays. You could also wrap this into a subroutine VI to limit the overhead of a subVI call. If the arrays going into the subVI are in-place, then there's virtually no overhead involved.

Your point is well taken that analyzing these situations takes a bit of trial and error, but I think LabVIEW's strengths currently lie in building whole systems efficiently rather in giving users the ability to control every tiny detail. If there are certain operations you are more familiar with in C, you can of course build custom DLLs to handle these routines. There's overhead in the DLL call itself, but you're at least much more in control of the memory operations.



Just my 2 cents.... Have a nice weekend 🙂

Message Edited by Jarrod S. on 03-30-2007 03:17 PM