From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
10-18-2017 04:22 PM
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.
10-25-2017 05:46 AM
t seems that there is no way to da that in LV:
https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-an-option-to-remove-items-in-memory/idi-p/3111220
10-25-2017 06:53 AM - edited 10-25-2017 07:02 AM
@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.
10-25-2017 08:10 AM
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.
10-25-2017 09:06 AM
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.
10-25-2017 09:33 AM
@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.
10-25-2017 12:41 PM
Makes sense but I am not up to challenge 🙂
10-26-2017 01:55 AM
Doubling your ram will be cheaper, even if you have 50 systems.
10-26-2017 02:53 AM
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
10-26-2017 04:26 AM
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?