memory efficient sub array

[jyang72211]

In a subVI, an user would select multiple elements randomly from an array through a tree control and output the sub-array.  Below are a two ways that I am thinking about.  I am wondering are there more and better options.

1. The most straight forward way would be to create a new array based on what are selected from the original array.  More memory but straight forward.

2. Make the elements of the original array into clusters of the original data type and a boolean to indicate is an element selected or not.  Doesn't have to create another array, but the original array becomes a little more complex.

A side question

After a subVI is done running and output the result to the next node down the chain, the data in the shift registers of the subVI is still in memory, right?  Is there a way to clear out the memory usage of the subVI after it is done running?  If I preserve the memory that way, would i have a penalty? 

[Mark_Yedinak]

There is a VI named "Request Dealocation" which you can call. However there is no guarantee that LabVIEW will release the memory. It may determine that it should keep it.

[altenbach]

Can you be a bit more specific?

Is this a 1D array and how big is it? How big are the selected sub-arrays?

What is your LabVIEW version?

Can you show us some code?

Chances are that it would be detrimental to request deallocation in the subVI, because most likely the memory would need to be reallocated at the next call of the subVI again, but at a cost.

Why does the subVI have shift registers? Is the subVI the interactive part that allows the selection? Remember that if the front panel of the subVI is open, you also have data copies in the indicators, transfer buffers, etc.

Maybe it would be sufficient to return an array of indices of the selected elements?

[crossrulz]

---

@jyang72211 wrote:

1. The most straight forward way would be to create a new array based on what are selected from the original array.  More memory but straight forward.

---

Since it sounds like you already know how many items were selected, preallocate the array and replace the elements instead of using the build array.

---

jyang72211 wrote:

After a subVI is done running and output the result to the next node down the chain, the data in the shift registers of the subVI is still in memory, right?  Is there a way to clear out the memory usage of the subVI after it is done running?  If I preserve the memory that way, would i have a penalty? 

---

There is the Deallocate Memory node.  But there is a penalty for every call the the subVI because LabVIEW has to keep reallocating the memory space.  I only use that node if I have a HUGE array in the shift register and I'm not using the VI "a lot".

[nathand]

Have you considered how much memory an array actually requires? Let's say you have an array of double-precision values (8 bytes each).  An array of 65000 consumes only 1/2 mb of memory (in a shift register; a front panel control may be double that or more due to buffering for display). Most likely your computer has well over 1gb of memory, so we're talking a tiny fraction of that (0.05% of 1gb). If your user can click on an element every half second, it would take 9 hours for them to select every element (65000 elements * 0.5 seconds/element * 1 min/60sec * 1hour/60min = 9 hours). I have trouble believing that your user is going to select that many elements.

The bigger issue is avoiding making copies of the array, because copying is relatively slow. This is why you usually shouldn't use build array in a loop - every loop iteration requires allocating a new, slightly-larger array, then copying the previous array into the new space. This can also lead to memory fragmentation, where there's plenty of memory available but it's broken up into small blocks separated by data that's actively used so there's no way to allocate a new large contiguous section.

Either of your approaches can work fine, as well as Altenbach's suggestion that you maintain a new array of indexes into the existing array. It depends on what you're doing with the data. Your concern should be avoiding unnecessary copies, rather than total memory use. Of course, if the user is only going to select 5 elements, then it probably doesn't matter at all.

[jyang72211]

If "Request Dealocation" is called inside the subvi, would the subvi still output the array into the next node?  I asssume so.  If that's the case, what memory are deallocated and which are not when the request is called?

[jyang72211]

Each element of the 1D array contains a file path name.  For my application, the array won't be too big, just a 2000 at most.  However, I just want to know what's the best way to handle the memory.  

The sub-array size is undetermined.  The subvi is the dialog that allows the user for selection.  It is up to the user.  My LabVIEW version is 2011 and 2012.  

Returning the indices would be a way.  For that method, I already have to return my original array though.

[jyang72211]

You are right. I kept thinking that I don't kow how many elements for the new array, since it is determined by the user through selecting items in a dialog.  However, after the user has made the selection, I would know, and I can preallocate the array at that point.

[Yamaeda]

---

@jyang72211 wrote:

In a subVI, an user would select multiple elements randomly from an array through a tree control and output the sub-array.  Below are a two ways that I am thinking about.  I am wondering are there more and better options.

1. The most straight forward way would be to create a new array based on what are selected from the original array.  More memory but straight forward.

2. Make the elements of the original array into clusters of the original data type and a boolean to indicate is an element selected or not.  Doesn't have to create another array, but the original array becomes a little more complex.

A side question

After a subVI is done running and output the result to the next node down the chain, the data in the shift registers of the subVI is still in memory, right?  Is there a way to clear out the memory usage of the subVI after it is done running?  If I preserve the memory that way, would i have a penalty? 

---

Use solution 1, and if you want to clear the sub-vi's register, either send an empty array to the register as part of the operation, or implement a clear-method which does that.

/Y

[Mark_Yedinak]

---

@jyang72211 wrote:

You are right. I kept thinking that I don't kow how many elements for the new array, since it is determined by the user through selecting items in a dialog.  However, after the user has made the selection, I would know, and I can preallocate the array at that point.

---

Well memory management is a good thing to keep in mind you may spend more time trying to be efficient than just letting LabVIEW do it's own thing. Your arrays are not that large and you really won't be saving much space. For what you described I wouldn't worry about the memory.