Minimize VI memory allocation and free operations

[charlie87]

Hello,

I am working on an application for long term use. It processes data continuously, that is, it gets data (matrix), calculates some matrix operations and returns results (cluster of matrices). When I use DETT, I can see repeated "processing VI allocate memory XXXX" and "processing VI free memory XXXX". My opinion is that the memory can be allocated once and not free untill it is explicitly needed. This way I would minimize memory operations. I have no idea, how to make the VI to hold the memory...

[GerdW]

Hi charlie,

---

@charlie87 wrote:

I have no idea, how to make the VI to hold the memory...

---

We neither! (No code, no help…)

Mind to share your VI?

[mcduff]

I have sen similar DETT traces for some of my code and I do not like it either. I am not sure how accurate DETT is. For example, you have a memory resize in your code where the change is 0, you also have a memory address of 0x00000000 which does not seem correct. (I see the same things in my traces.) I am guessing you are using DVRs as in my experience this can gives some of what you see. Another things that I think give the same result in DETT, autoindex an array in a For Loop for an input, do some operation on the data, then index the output. You can use a shift register instead to get rid of the funny DETT traces entries, but I don't think it leads to any performance improvements.

[Kyle97330]

One thing that can help understand memory allocation is using the Show Buffer Allocations option on your VI.

One of the better ways you can reduce memory usage is by reducing the amount of array resizes that occur.  I don't know how possible or easy it would be to do in your application, but if you allocate a single large array at the start and never resize it, it can use less memory than creating an empty array and then letting it grow over time.

You can also reduce array memory use, and memory use of some other data types, by operating on them using the in-place structure, as long as you use the assorted modifiers it comes with:

[altenbach]

---

@charlie87 wrote:

I am working on an application for long term use. It processes data continuously, that is, it gets data (matrix), calculates some matrix operations and returns results (cluster of matrices). When I use DETT, I can see repeated "processing VI allocate memory XXXX" and "processing VI free memory XXXX". My opinion is that the memory can be allocated once and not free untill it is explicitly needed. This way I would minimize memory operations. I have no idea, how to make the VI to hold the memory...

---

Based on the parse information, I am wildly guessing that your code might not be optimally designed, but I will postpone any detailed response until I see some code.

• How long is "long term"?
• What is your definition of "continuously"?
• What is the rate, amount of data, etc.
• Typically "simple data" is in the form of arrays (1D or 2D) (lets, put aside dynamic and waveform data). A "matrix" datatype in LabVIEW is basically a "special" 2D array that is mostly used in linear algebra. Is that what you are doing?
• What is a "cluster of matrices" (Why? How many elements? What data sizes? Are the sizes constant?, etc.)
• What kind of matrix operations?
• Assuming that each data gulp is of the same size,  I am sure it could be designed fully in-place.

Awaiting to see some simplified code.

[wiebe@CARYA]

---

@charlie87 wrote:

Hello,

I am working on an application for long term use. It processes data continuously, that is, it gets data (matrix), calculates some matrix operations and returns results (cluster of matrices). When I use DETT, I can see repeated "processing VI allocate memory XXXX" and "processing VI free memory XXXX". My opinion is that the memory can be allocated once and not free untill it is explicitly needed. This way I would minimize memory operations. I have no idea, how to make the VI to hold the memory...

---

The code would indeed be helpful.

But also, why do you want to minimize memory operations?

Do you see extensive memory usage?

Or is your CPU% too high?

Reducing memory usage will help for both, but if CPU% is the problem optimizing the algorithm will probably help more.

Those matrix functions use CLFN extensively, and there's little control over the memory it requires.

[altenbach]

---

wiebe@CARYA wrote:
Those matrix functions use CLFN extensively, and there's little control over the memory it requires.

---

Users with certain backgrounds call any 2D array a "matrix". We would need to know what these operations really are and my gut feeling (>50% probability) is that these really are just plain 2D arrays.

As overheard in "the Matrix": "red pill or blue pill?" 😄