IPE and Mark As Modifier

[KuGr]

Actor.lvclass:Receive Message.vi wraps the call to Message.lvclass:Do.vi with an IPE having the Actor In Place In / Out Element border node tagged with Mark As Modifier.  How far does this reach?

Actors might have additional classes in their cluster of private data.  A received message will likely alter objects in the private data.  Those objects may also have 'imbedded' objects and so on.  Does the Mark As Modifier tag at the Receive Message.vi account for the modification to contained objects or should calls to a Dynamic Dispatch vi be wrapped in an additional IPE as they are likely to be modified in that call?  I do not think that they should have Mark As Modifier as that would force and additional copy already created by Receive Message.vi.

If the objects are held as variants in some sort of collection and operated on individually, should an IPE be used?

If the embedded object is a DVR to a class, should a Dynamic Dispatch call with the dereferenced DVR object be wrapped in and IPE? And in this case should they have Mark as Modifier?

Does it hurt to wrap calls to VIs in IPEs and use In Place In / Out border nodes (without Mark As Modifier)?

I am asking this because I am seeing some large memory consumption (400MB) when running over a month.  I was able to reduce the consumption by some judicious used of IPEs but not all of the consumption is eliminated and my runs are shorter in order to troubleshot ideas.

I have not run DETT recently, but typically all memory (except the Actor.vi opened in Launch Actor Core.vi) is accounted for when the app shuts down.  It seems more like LabVIEW is making copies it cannot or will not reuse.  We run in the IDE, I am running LV2016 32-bit on Win7 64-bit.

Thanks for your help.

Kurt

[KuGr]

OK, let's start off with a 'simpler' inquiry.

As I research IPEs and memory allocation, I get the sense that I should not have to use IPEs unless I am sure of the in-place-ness of the code inside the IPE.

In looking at ReceiveMessage.vi, how can I be sure of the in-place-ness of the message's Do.vi?

AQ's "safety blanket" aside (see his comment in ReceiveMessage.vi), why is the IPE still there?  Based on my empirical findings in a similar command pattern approach in my code, I could argue that it is still needed.

[paul.r]

If memory consumption is steadily increasing while your application runs, I doubt it has anything to do with IPEs - you most like have a memory leak somewhere else in your code.  

The vast majority of applications I write are AF based, and I usually only use IPEs if I am trying to optimize some operation. I have only seen memory growth issues when I have a memory leak in my code. 

[FabiolaDelaCueva]

Hi Kurt,

Besides Desktop Execution Trace Toolkit, you can also use Tools>>Profile>>Profile Performance and Memory... menu option. These two options are mentioned in this lengthy but useful link: https://zone.ni.com/reference/en-XX/help/371361R-01/lvconcepts/vi_memory_usage/

You probably already know most of that, but there might be a hidden sentence that might make the difference for you.

Another less known tool is the Tools>Profile>>Profile Buffer Allocations... http://zone.ni.com/reference/en-XX/help/371361R-01/lvhowto/profiling_buffer/

I hope this helps.

Regards,

Fab

[KuGr]

Thanks Fab and Paul.  I have seen that document, but I do get more out of it each time I read.

The Profile Performance and Memory provides lots of data and I have not been able to sort it out.  I am guessing I need to compare snapshots to see who the culprits are.

The interesting thing about the IPE is that when I put it in a "User Event" case in an Event Structure that mimics the AF message Do approach, it substantially reduced the memory consumption.  Right now I am down to about 100 to 200K per day from closer to 10-20M.  Basically a 100 to 1 reduction.  I am testing while the unit is not in production and will have real-world numbers beginning next week.

In another case of adding IPEs, I get horrible results - huge upfront memory consumption.  So, I agree, they are not always the solution.  Also for me (clearly) and others are very misunderstood.

I see leaks as coming from two primary sources.  Memory fragmentation and unreleased allocation.  Paul, what you are suggesting is that I have unreleased allocation.  So possibly obtaining references from LabVIEW and not Close-ing them.  Would those show up in DETT?  I just ran that yesterday and I did not see anything unexpected.  I do have more than I thought, but they are allocated at startup and not released at shutdown - not repeated throughout running code.

I do obtain (and retain) VI and control references later released at application shutdown.  If I call a method with a VI Ref as an input terminal, do I need to release that ref?  When I look at the Buffer Allocations, there is an indication that the VI Ref terminal has an allocation, but is that just the bytes necessary for the ref, or is the ref actually now a copy that needs to be released?  Similarly for an array of Control Refs.  While I do not pass them into a subroutine, they are pulled from a class's private data (stored at startup) and used to update via property nodes when the control index is not appropriate (UI controls within typedef controls).  I see no Allocation Buffer dots so I expect that this not making reference copies.

Any other suggestions on what to look for?  I am actually thinking of disabling the UI updating process to see how that affects the memory usage.

As always, thanks for your help!

-Kurt

[KuGr]

I suppose ever growing arrays and unhandled messages. I will look into that but that will be tough.