labview memory performance

[adcpc]

Hi,

I'm using a DAQ board to do some large data acquisition (200 MHz sampling, 32 bits resolution, 2 channels, 100 ms length). Then, I write both channels values to a binary file. With the previous parameters, this should result in around 76 MBytes files. The real result is 78 MBytes for each file. The main issue is that I'm limited to around 150 ms acquisition length. If I try to get a longer acquisition, I get a memory full error. The system runs on Win XP 32 bits with 3GB of memory. As it is 32 bits, LabVIEW can use 2GB max.

Using the performance and memory analysis tool of LabVIEW, I've seen that my VI uses up to 160 MB of memory which is efficient as I'm working with a 156 MBytes (2x78) data set. However, if I have a look at the Windows Task Manager during the VI execution, I can see that LabVIEW.exe memory usage goes up to 600 MBytes. Why is there such a difference between memory used by my VI only and memory used by LabVIEW.exe ?

Thanks,

Alexandre

[Yamaeda]

The library package that is LabVIEW runtime must be in memory also. 🙂

/Y

[adcpc]

Yes, I understand that but this package should have a more or less constant memory usage once necessary functions have been loaded. If I do a 10ms acquisition (16 MBytes of output data), the memory consumption of LabVIEW.exe goes up to 150 MBytes (memory usage of LabVIEW without any loaded VI is around 90 MBytes). If I do a 100ms acquisition (160 MBytes of output data), memory use goes up to 600 Mbytes. 

It seems that LabVIEW uses around 4 times the memory I really need.

[Ben]

Let me start by sharing this tag cloud about LV performance.

Linked to those cloud entries you will find various thread devoted to performance with memory being a big tiem in that area.

LV does a good job of masking the nasty little details of memory from us that we may get blind-sided when we gear up to high speed acquistions.

Since you did not post code or a full diescription I have to specualte that you have some buffer duplication taking place for one reason or another. Please look closely at the cloud for buffer allocations.

Other things that can casue memory usage.

Changing representation from singe to double.

Are you calcualting based on your actual data size?

Default values in displays.

Duplicated when writting to file.

and many many others.

Again that tag cloud should lead you to the answer you seek.

With more detiasl we can be of more assistance.

Ben

[adcpc]

Here is the critical part of my code :

The call to the .NET Dll has been renamed but everything else is used as shown above.

With acquisition time set to 100 ms and sampling frequency to 200 MHz, I can see that the memory allocation is increased by 160 MBytes when reaching the initialize array part. This is expected. However, after the DLL call, there is another 160 MBytes memory increase which I don't understand. I don't know if I'm doing something wrong or if the DLL function is doing a copy of the data and not releasing the memory afterwards.

Parameters of the DLL call :

Error out : Error code

Samples to Capture : Number of samples that have to captured from the instrument

Buffer A and Buffer B : Pointer to buffers of floats

Both buffers are initialized with required size of 32 bits floats.

The write to binary file is done correctly as the required memory for this operation is immediately released when calling the "close file" function.

Any idea on how to improve this ?

Thanks

[Yamaeda]

Do you open the instrument ref at some other place? Else you have a ref definition which you close, not an object. Add an Automation open in between the ref and the invoke node and tell us if it's better.

/Y

[adcpc]

The instrument reference is previously created by using a constructor node which loads the required .NET assembly.

[Ben]

---

@Alexandre.DaCosta wrote:

The instrument reference is previously created by using a constructor node which loads the required .NET assembly.

---

Am I correct in understanding that the extra close I see in your screen shot is closing the .net stuff?

If so that may be you memory leak. Try to open it once and work the open ref until you are done.

It may also be worth while to comment out the .net stuff to see if you can narrow down where the memory is escaping.

Ben

[adcpc]

Sorry, the screenshot was in fact wrong. Here is the correct one :

The first "close ref" is used to close the "subproperty" reference. The second one is used to clear the "property" reference. The instrument .NET reference is close immediately after the execution of this VI.

If I comment out the .NET capture method, I have memory (160 MB) allocated for the 2 buffers but they are correctly deallocated at the end of the VI execution.

If I don't comment it out, I have 320 MB allocated but, 2 out 3 times, only half of it deallocated at the end of the execution.

Thanks,

Alexandre

[Ben]

---

@Alexandre.DaCosta wrote:

Sorry, the screenshot was in fact wrong. Here is the correct one :

The first "close ref" is used to close the "subproperty" reference. The second one is used to clear the "property" reference. The instrument .NET reference is close immediately after the execution of this VI.

If I comment out the .NET capture method, I have memory (160 MB) allocated for the 2 buffers but they are correctly deallocated at the end of the VI execution.

If I don't comment it out, I have 320 MB allocated but, 2 out 3 times, only half of it deallocated at the end of the execution.

Thanks,

Alexandre

---

So you are thinking it is how you are using the .net interface then?

Did you try restructuring the code to only get the sub-property ref once and only do the method inside the loop?

Similarly with initializing that buffer used for the return data.

Ben