Unload LBLIBP from LV memory

[crossrulz]

---

@peper2001 wrote:

Is this expected behavior?

---

Is plugin 2 using a reference (for example a queue) for plugin 1?  That would make plugin 1 stay in memory until everybody with that reference releases it (ie, plugin 2 closes the reference).

[peper2001]

Hi,

No apart from the fact that they both inherit from "PluginInterface.lvclass" (which is also built as a PPL), plugin 1 and plugin 2 do not interact with each other…

[peper2001]

Attached is a video of what I observe:

- First I launch plugin1, it loads in memory, runs for 3s and leaves memory

- After I launch plugin2, it loads in memory, runs for 10s and leaves memory

- Then I launch plugin2, and while it is running, I launch plugin1. Plugin1 stops before plugin2 but stays in memory, then plugin2 stops and both plugins leave memory.

I did the last action twice.

I'm trying to share the code but it was written in LV2019 64bits and I assume most people won't be able to load it. I'm looking for a way to convert it to 32bits.

[pawhan11]

If they both share interface they will unload when interface unloads. That would mean when async vi using interface goes idle.

How long it takes to load and unload plugin?

[peper2001]

Hi,

In my test project, the plugins launch very fast because they basically do nothing. 

I'm more concerned about the memory that each plugin uses, not being freed up by LabVIEW.

I made a new test where each plugin, loads the same big array of double in memory. What I observe in terms of memory consumption:

- 550Mb when no plugin are running

- 780Mb when plugin2 is launched 

- 1000Mb when plugin1 is launched (while plugin2 is still running)

- still 1000Mb when plugin1 stops

- 550Mb when plugin2 stops

So memory is not being freed when plugin1 is stopped.

I'm not sure if it is a problem or not because if I launch a new instance of plugin1 right after the previous instance has stopped (and while plugin2 is still running), memory stays at 1000Mb. Which seems to indicate that the garbage collector has not freed the memory but LV is still able the reuse the memory?

It also seems that using the "request delallocation" flag actually frees part of the memory but not all of it.

On the video, I launch plugin2 and then plugin1 with and without the deallocation flag. With the deallocation flag on, while memory should go down to 400Mb when plugin 1 stops, it only goes down to 550Mb.

[Yamaeda]

You have to understand that LV has a memory manager of its own, and requesting memory from Windows is fairly costly. It might very well deallocate the memory internally, but not give it back to windows so it can be reused, as when you reopen Plugin1.

Do you run into performance issues or is it mostly a case of "how do this work"?

/Y

[peper2001]

I would like to make sure that, when plugin1 stops (while plugin2 is still running, so memory is not freed up), another plugin can reuse the memory of plugin1.

The situation I would like to avoid is: a user loads plugin2, then loads plugin1. Plugin1 stops and the user tries to load plugin3 which fails because of a out of memory error. Provided plugin1 and 3 use the same amount of memory, the user will probably wonder why loading plugin3 failed despite the fact that he stopped plugin1.