LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

memory usage changes/increase in a strange way ...

Hello,

 

It's me again - the one who wrote a code so long that nobody can even read it 🙂

 

http://forums.ni.com/t5/LabVIEW/Help-needed-Memory-leak-causing-system-crashing/td-p/1713886

 

Anyway, after getting help from here, I made some changes like moving the DAQmx tasks outside loop and etc (but no structural changes I could have done so far because of other works) and used the Windows' Administrative Tools » Performance  to monitor the memory that been used by my program (I run the excutable on a standalone PC). One thing for sure is that now memory usage not growing like crazy no more, but it seems strange to me. Below image is I reploted in Excel just for better reading.

 

This data were recorded continously from 9/23 to today, and I monitored only one process excution which is my code. You can see that the memory usage was not increasing all the time but more like step changes. It kept at a constant level for hours or even days and then all the sudden jumped up (or down, but small amplitude) to a new value. You can see there was a almost 3-day period that the memory usage is stable at ~44.6MB.

 

I don't know how to explain this. Is it still memory leak? But how can it leak like a step function? There is no action besides regular reading/writing. I aslo tried to use DETT but this kind of random events hard to capture and DETT records way too huge dataset that I cannot open.

 

Can any of you guys point me some direction to go? Or let me know what your guess is? I am not sure how many people monitor the memory usage of their code but this is really taking long time to test and hard to identify.

 

Thanks in advance,

 

Rgds,

 

Harry

 

MemoryUseChart.jpg

0 Kudos
Message 1 of 5
(1,108 Views)

Harry W.

 

After looking at your code from the previous thread, I would have to give you kudos on your organization and documention. But there are a number of things concern me, specifically the use of: local variables, sequence structures, DAQ assistant &multiple DAQmx calls, Dynamic Data Type, and massive arrays.  Each of these things will contribute to your memory leak and overall program performance. To fix these issues, follow these general guidelines:

 

1. Avoid the use of local variables (especially a large number of them). Use Queues instead.

2. Avoid the use of sequence structures.  These produce large VIs and are usually unnecessary. Instead, use the natural data flow inherent in wiring and SubVIs. If your block diagram doesn't fit on your monitor, then it's too big.

3. Avoid using the DAQ assistant and creating multiple DAQmx tasks in loops.  Tasks can generally be combined and created outside of loops then called later for use inside the loop.

4. The Dynamic Data Type is better suited for smaller applications with less 'action'

5. Avoid building large arrays.  These will almost always cause the memory use to build up and leak.

 

I would encourage you to visit the example VIs preloaded with LabVIEW. Specifically, I would look at State Machine, Producer/Consumer, and Master/Slave architecture.

 

Please note: Unless you have an entirely new issue, it is bad practice to start a new thread.  Please keep posts addressing same issue in the original thread.

 

Alexander M

Applications Engineer

National Instruments

0 Kudos
Message 2 of 5
(1,069 Views)

Alex,

 

Thanks for your comments. I have some follow up questions here.

 

1. Avoid the use of local variables (especially a large number of them). Use Queues instead.

I don't quite understand how to use Queues to replace the local variables. Can you point an example or reference?

 

2. Avoid the use of sequence structures.  These produce large VIs and are usually unnecessary. Instead, use the natural data flow inherent in wiring and SubVIs. If your block diagram doesn't fit on your monitor, then it's too big.

Yes this is what other ppl suggested last time and I plan to do so.  

 

3. Avoid using the DAQ assistant and creating multiple DAQmx tasks in loops.  Tasks can generally be combined and created outside of loops then called later for use inside the loop.

Yes in my latest code I removed the DAQ assistant and took the DAQ tasks out of the loop. I think this helped on reducing leak.

 

4. The Dynamic Data Type is better suited for smaller applications with less 'action'

The Dynamic Data is associated with DAQ assistant right? I think I got rid of those already.

 

5. Avoid building large arrays.  These will almost always cause the memory use to build up and leak.

This is something I really want to get better. How can I avoid building arrays? Is a 1X8 array considered as large array? In our application, we have 7 AI inputs which we need to work with every cycle, and generate 7 AO. Can you give me some hint how to avoid building arrays?

 

BTW, can you give me the reference # so I can talk to you if needed? Thanks

 

Thanks

 

Rgds,

 

Harry

0 Kudos
Message 3 of 5
(1,055 Views)

Harry,

 

It's good to see you were able to implement a few community suggestions.

 

I was able to find an example that compares Queues and Local Variables and demonstrates certain pitfalls.  I have attached the example to my post.

 

As far as arrays go, a 1x8 array is not considered large, you should be fine with that.  Where most people run into issues when building arrays in a continuous while loop, as shown below:

BadBuildArray.PNG

The method above is a perfect example of poor programming.  This will directly affect memory performance after a period of time.  I'm not sure if this technique is present in your code, I just wanted to point it out.

 

SR# 1744921

 

Alexander M

Applications Engineer

National Instruments

0 Kudos
Message 4 of 5
(1,040 Views)

Thanks Alex, I'll see if i can make improvment based on your suggestions.

 

Harry

0 Kudos
Message 5 of 5
(1,032 Views)