LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW Memory Management VI question, a special request to you

Solved!
Go to solution

I'm trying to understand what I am doing.

 

I'm working on something that uses up LabVIEW memory such that I get an out of memory error pop-up, and I'm trying to understand it.  To this end I created a vi that I am posting.  I have a special request.

 

Please explain to me, as best as you understand it, what this posted vi does, even if you think it is dumb and doesn't make any sense.

 

Thank you fellow LabVIEW users.  

 

Note: This VI is LV2018.

 

0 Kudos
Message 1 of 35
(1,465 Views)

Here's the block diagram:

 

3d0g_0-1697143759083.png

 

 

 

 

 

0 Kudos
Message 2 of 35
(1,461 Views)

Here's the front panel:

 

3d0g_0-1697143937671.png

 

 

0 Kudos
Message 3 of 35
(1,458 Views)

The CLFNs are:

 

DSNewPtr:           uintptr_t DSNewPtr(int32_t size);

MoveBlock:          void MoveBlock(uintptr_t pSource, int16_t *pDest, int32_t size);

DSDisposePtr      int32_t DSDisposePtr(uintptr_t p);

 

in order from left to right.  Four such are stacked vertically, but dataflow is dataflow.

 

All functions are from the LabVIEW library.  (Enter "LabVIEW" for library name or path.)

 

Also, the vi contains a Data Value Reference and a read/write mechanism for such, or at least such as I understand it.

 

 

0 Kudos
Message 4 of 35
(1,450 Views)

 

Here's a successful run of the vi:

 

3d0g_1-1697144729588.png

 

0 Kudos
Message 5 of 35
(1,447 Views)

I have not measured the memory usage of your VI. You duplicate the 140e6 Byte buffer about 16 times ... not really a good idea.

Message 6 of 35
(1,415 Views)

I looked at the memory usage, assuming I used the newly discovered tool correctly (under tools - profile - performance and memory),

 

Here's start:

 

 

3d0g_0-1697151899951.png

 

Here's finish:

 

3d0g_1-1697152055669.png

 

Those are killobytes. 

 

Therefore, that's 1960016.44KB = 1.96 GB

 

Correct? 

 

 

0 Kudos
Message 7 of 35
(1,406 Views)

Will you please elaborate a little, Martin?

0 Kudos
Message 8 of 35
(1,401 Views)

@*3d0g wrote:

Will you please elaborate a little, Martin?


It's difficult to tell what the compiler actually does.

 

I counted the knots plus the FP elements. In reality, the footprint may be smaller, but I'm certainly not entirely wrong. 

snip.png

 

BTW: I do not really trust the labview performance monitor and I do not trust the "show buffer allocation". In examples like this, the information should be compared with the allocations reported by the operating system. 

 

(corrected the picture (position of memory allocation 2,3 and moved 4,5,6,7 to DSNewPtr)

Message 9 of 35
(1,369 Views)
Solution
Accepted by *3d0g

Hi 3d0g,

 


@*3d0g wrote:

Please explain to me, as best as you understand it, what this posted vi does, even if you think it is dumb and doesn't make any sense.


What's the point of creating the DVR?

You init an array, put that into the DVR, then you read the array from the DVR, then you dispose the DVR. There is no place where you actually use the DVR to manipulate data inside the InPlaceElement structure…

 

The main usage of a DVR is to provide a "pointer" (aka reference) to a data structure so you move that small reference instead of large data structures along the DATAFLOW. You manipulate the data referenced by the DVR inside an IPE structure.

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 10 of 35
(1,359 Views)