How do you avoid unneccesary "array copies"?

[peter-biomed]

Hello - I have been having significant difficulty trying to optimize my code as I have been finding that LabView tends to make copies of variables almost everytime you access them. This may not be a big deal some times, but in my case, I am using arrays that are 10MB in size or greater, and making duplicates of them not only wastes memory, but also time. I would like to figure out a way to avoid this. From what I can see, using a continuous thread with shift registers and sequence locals can reduce some of the duplication, but generally that becomes a wiring nightmare in the diagram. Also, one thing that I would like to do is keep some of these arrays within a record format, but I think anytime you have a wire coming out of a
bundle, a new copy of that variable is made. I'd like to be able to use pointers, but someone from NI told me pointers were a "bad word" in LabView and references obviously don't work the same.

Any ideas would be appreciated (sorry the text is long).

[Dennis_Knutson]

Select Search the LabVIEW Bookshelf from the Help menu and scroll through until you find the application note "LabVIEW Performance and Memory Management". In there you'll find a section called Rules for Better Memory Management. Some things you should be avoiding is local and global variables, the Build Array function, unnecessary front panel displays, and data type coercion. Effecient methods of using the bundle/unbundle are also discussed.

[peter-biomed]

Thanks Dennis for your post.
I have read that document, and especially in terms of the bundling/unbundling, it more or less just states to avoid it which for my application may not be the easiest solution. Also, in it a phrase reads "Each level of unbundling/indexing might result in a copy of that data being generated". I'm trying to figure out when "might" becomes "does" or "doesn't". Also, I have seen the consequences of using locals, globals and "value" property nodes. I wonder why LabView requires making a copy when these are used (because programatically within the scope of the diagram they are much easier to use then sequence locals and shift registers). thanks.

[Trager]

you might want to add the following to your .ini file:

showInplaceMenuItem=True

Doing so will let you know when and where you are making copies of data.

[Greg_McKaskle2]

> I have read that document, and especially in terms of the
> bundling/unbundling, it more or less just states to avoid it which for
> my application may not be the easiest solution. Also, in it a phrase
> reads "Each level of unbundling/indexing might result in a copy of
> that data being generated". I'm trying to figure out when "might"
> becomes "does" or "doesn't". Also, I have seen the consequences of
> using locals, globals and "value" property nodes. I wonder why LabView
> requires making a copy when these are used (because programatically
> within the scope of the diagram they are much easier to use then
> sequence locals and shift registers). thanks.

First, I'll comment on the local and value property. If the AE really
said that pointers are a dirty word in LabVIEW, what they really meant
was that LabVIEW works on dataflow and really doesn't expose the pointers.

The upside of this is that it is much less likely that you will have
uninitialized values, stale pointers, memory leaks, etc. You also have
much clearer idea of what is happening to your data, and parallelism is
much easier to see/use. The downside is that you have less control.
Also, it is best not to think of the reference as a pointer/reference to
data, but instead it is a reference to a UI object, the control or
indicator.

Locals and reference->value are convenient when you are used to writing
lines of code, or expressions that move the data from one location to
another. This code is typically using a sequence to make lines of code
where each of them loads what it needs, modifies it, then stores the
results. Again, this feels familiar, but it is not what works well in
dataflow like LV. It works much better to largely get rid of the
sequences and simply let the data dependency do the work.

Doing this should automatically help your memory usage provided you keep
the items in the performance chapter in the back of your mind. Also,
remember that subVIs normally don't hurt memory usage provided their
panel is not open, and they can even help with memory usage as storage
buffers can be reused.

For the unbundle issue, hopefully your have an array of rather small
records, but in the event you have a record with large arrays, you do
need to avoid repeatedly accessing the elements, indexing, etc. You may
want to build a data access subVI that can do the indexing, searching,
etc in a common location and avoid returning the big arrays. This also
allows for the storage to be moved to a shift register and the whole
thing becomes a functional global.

You might want to spend a little time browsing through the examples for
smart or functional globals as well as some of the analysis ones that
process arrays to see how they deal with the sequencing and wiring.

Greg McKaskle