LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

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 27
(3,656 Views)
0 Kudos
Message 2 of 27
(3,604 Views)

@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 27
(3,595 Views)

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 27
(3,578 Views)

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 27
(3,571 Views)

@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 27
(3,565 Views)

Makes sense but I am not up to challenge 🙂 

0 Kudos
Message 7 of 27
(3,555 Views)

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

0 Kudos
Message 8 of 27
(3,542 Views)

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 🙂 and has no benefits at all

0 Kudos
Message 9 of 27
(3,539 Views)

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 27
(3,526 Views)