cancel
Showing results for 
Search instead for 
Did you mean: 
Reply

Unload LBLIBP from LV memory

Unload LBLIBP from LV memory

Hello Dear Users,

 

I am using packed project libraries inside my application to define basic actions. I call child implementations dynamicly by using packed project libraries. For example I have multiple tests, each of them after is loaded never leaves memory. Can I force Labview to remove this packed project library from memory once it is not used? If Yes how? It propably stays in memory because parent class is constantly in memory. If this is not possible will this feature be implemented? Because now all plugins will be eventualy loaded into memory and on small memory devices this is a problem.

0 Kudos
Message 1 of 19
(692 Views)

Re: Unload LBLIBP from LV memory

0 Kudos
Message 2 of 19
(640 Views)

Re: Unload LBLIBP from LV memory


@pawhan11 wrote:

t seems that there is no way to da that in LV:


There no way to do this manually, because as the first answer (highly recommended to take seriously) states: this always happens automatically.

 

If objects stay in memory, you must refer to the object. Make sure you close all references and other usage, and they will disappear from memory automatically.

 

Pretty sure parents don't make the children stay in memory.

 

The idea is about removing classes from memory in development environment. Then again, the thread is inconclusive about whether classes are or are not unloaded from executables automatically.

0 Kudos
Message 3 of 19
(631 Views)

Re: Unload LBLIBP from LV memory


wiebe@CARYA wrote:Then again, the thread is inconclusive about whether classes are or are not unloaded from executables automatically.

Re-reading the idea exchange item, classes should be removed, but only when all ancestors are removed from memory. The parent can only be unloaded when all children are unloaded... That might be tricky with a plug-in structure, depending on the exact setup.

0 Kudos
Message 4 of 19
(614 Views)

Re: Unload LBLIBP from LV memory

When using setup that we have base class that defines framweork and we call another ppls that will override this one they are never removed since their partnt is always in memory by definition.

0 Kudos
Message 5 of 19
(607 Views)

Re: Unload LBLIBP from LV memory


@pawhan11 wrote:

When using setup that we have base class that defines framweork and we call another ppls that will override this one they are never removed since their partnt is always in memory by definition.


Well, even then you could (theoretically) dynamically load the parent and the children, then unload them all when possible. That is just theory. Problem is you need to make all the calls dynamic as well, since normal polymorphism won't work, since there is no way to define the interface. Maybe if the dynamic calling is wrapped up in a class (mirroring the interface of the dynamically loaded parent) it won't be terribly bad. But indeed far from ideal.

0 Kudos
Message 6 of 19
(601 Views)

Re: Unload LBLIBP from LV memory

Makes sense but I am not up to challenge Smiley Happy 

0 Kudos
Message 7 of 19
(591 Views)

Re: Unload LBLIBP from LV memory

Doubling your ram will be cheaper, even if you have 50 systems.

0 Kudos
Message 8 of 19
(579 Views)

Re: Unload LBLIBP from LV memory

There is one more thing that I am not sure how works, when PPL is loaded int system and I make new revision.

After I replace this PPL will labview notice this is new version of old one and reload it? Or I have to restart main system? If I have to restart i am lead to conclustion that using ppls is pointless Smiley Happy and has no benefits at all

0 Kudos
Message 9 of 19
(576 Views)

Re: Unload LBLIBP from LV memory

I wouldn't know but isn't that easy to test? Make\modify a PPL with a messagebox, then update with another message?

 

Also interesting: will the old one be unloaded from memory?

0 Kudos
Message 10 of 19
(563 Views)