LabVIEW
Accessed class data copied when accessed in a dynamic dispatch vi
Hoping someone out there might be able to shed some light on this.
Summary:
1. "cc" object with large private data.
2. _parent object with children objects
3. children objects access cc in a dynamic dispatch vi
The result of this is a copy of the cc data for every child that accesses it.
The project attached is an example of this. Run the main in the cc.lvclass. Child 2 does not access the cc data and does not create a memory increase.
I know I can solve this by accessing the cc data outside of the dynamic dispatch vis, but maybe someone knows of a better way.
(mostly replying because I'm interested, but...)
Are you certain LabVIEW is actually using all of the memory you think it is? As I understand it, Windows will allocate memory to processes, but it might not actually be using it. I played around with your code some, and in some cases the memory usage went *down* after the 3rd run or so. I wonder if LabVIEW is "pre-allocating" memory it thinks it might need, but doesn't actually use it- so it would theoretically be available to other processes if they DID need it.
One of the reasons I mention this is because running the Profile Buffer Allocations tool shows only one buffer allocated per child class, but then again I'm not super familiar with that tool.
Turn on inlining on "get the big data.vi"
As is:
Inlined:
The compiler is less stupid about buffer copies with inlining on.
@BertMcMahan wrote:
(mostly replying because I'm interested, but...)
Are you certain LabVIEW is actually using all of the memory you think it is? As I understand it, Windows will allocate memory to processes, but it might not actually be using it. I played around with your code some, and in some cases the memory usage went *down* after the 3rd run or so. I wonder if LabVIEW is "pre-allocating" memory it thinks it might need, but doesn't actually use it- so it would theoretically be available to other processes if they DID need it.
One of the reasons I mention this is because running the Profile Buffer Allocations tool shows only one buffer allocated per child class, but then again I'm not super familiar with that tool.
I wouldn't be able to answer this but this is still a problem if you have a very large object.
@avogadro5 wrote:
Turn on inlining on "get the big data.vi"
As is:
Inlined:
The compiler is less stupid about buffer copies with inlining on.
That does resolve the issue in the attached code.
