Special LabVIEW Considerations when creating a DLL?

[LuminaryKnight]

---

@Yamaeda wrote:

LV is generally good at managing its memory, but it might still be considered active/used as long as Python runs. One Request deallocation as you exit should be enough, but if the DVRs work well, then go for it. 🙂

---

So, I took your advice and removed all "Request Deallocations" and just placed one at the top level VI ( I assume that's what you were suggesting) and my problem came back in full force.  So I gradually placed one in each subVI testing the result each time and watched it gradually go away.  However, it STILL takes almost 12 seconds before Python is able to move on.  Very confusing.  The task is quite literally done. There's a return from the DLL I print to the terminal (this is the very last task in Python) and the new parsed file is very clearly created in the folder and done.  But Python is still waiting on the memory of the DLL to be completely released.  I can see this in the task manager.

Sum up:  My statement about DVRs is apparently wrong.  That didn't make a difference.  Putting Request Deallocations in every Single VI seems to be necessary.  If you're working with 4GB of data as I am.

[mcduff]

If possible you should post some code. If you have the Trace Execution toolkit look at the memory allocations; you can see where buffers are created and whether they are released. Lastly sometimes even though the DVR or queue reference has been destroyed, the memory is not released. For these cases, before destroying the DVR or queue write "empty" values to it before destroying it. Here "empty values" means an empty array, waveform, etc. For the queue case you need to do this in a for loop for whatever the max size of the queue was.

EDIT: I work with other 4GB or more of data at times and never had to use the deallocation vi.

[LuminaryKnight]

---

@mcduff wrote:

If possible you should post some code. If you have the Trace Execution toolkit look at the memory allocations; you can see where buffers are created and whether they are released. Lastly sometimes even though the DVR or queue reference has been destroyed, the memory is not released. For these cases, before destroying the DVR or queue write "empty" values to it before destroying it. Here "empty values" means an empty array, waveform, etc. For the queue case you need to do this in a for loop for whatever the max size of the queue was.

EDIT: I work with other 4GB or more of data at times and never had to use the deallocation vi.

---

Unfortunately, I probably can't share code.  And I know that's not super helpful.  But... (and I understand if you have to say, "no", to this) would you be willing to do a video call code review?  Sounds like you're the guy to ask about this sort of thing.

[mcduff]

---

@LuminaryKnight wrote: Unfortunately, I probably can't share code.  And I know that's not super helpful.  But... (and I understand if you have to say, "no", to this) would you be willing to do a video call code review?  Sounds like you're the guy to ask about this sort of thing.

---

Maybe later, dealing with a snowstorm now. If you don't have the Trace Execution toolkit, go to the Tools Menu >> Profile >> Profile Buffer Allocations

There you will see where buffers are being created, look for copies of the same buffer, that is, wire branches, etc. For each buffer you find see if it is being destroyed.

As an example, this is a case not for you since you have a dll, but I had a subPanel that displayed data. When the subPanel was closed the memory buffer for the plot was not released. So before closing the plot, I wrote an empty waveform to it, and then the memory returned.