ACBR Proxy Caller/ Memory Leak problem

[bspoka]

Clever! Thanks AQ, I'll try this and report back.

[drjdpowell]

AristosQueue wrote:

I think I can make it work with even fewer data copies.

Excuse me, but that seems so redundant.  If the compiler cannot recognize such simple wrap/unwrap operations as not requiring a copy, then what exactly can it optimize?  Isn't this just overly-complicated code?

[AristosQueue (NI)]

drjdpowell wrote:

Excuse me, but that seems so redundant.  If the compiler cannot recognize such simple wrap/unwrap operations as not requiring a copy, then what exactly can it optimize?  Isn't this just overly-complicated code?

I think it is overly-complicated. As I said, I think this is something that the compiler could be taught to recognize.

[drjdpowell]

Mystifying.  This is so simple an optimization that I would be tempted to label it a bug rather than a lack of optimization.  These are one-wire-in-one-wire-out by-value operations; there is no wire branch!  What does the compiler need to recognize other than this?  This shakes my faith in LabVIEW to be able to handle even the most trivial of memory operations for me.  Do I really have to start using verbose and ugly code constructs everywhere?

[bspoka]

Not to defend any compiler shortcomings, but I think the point of this discussion is that this becomes an issue only when you're dealing with very large single blocks of data (>30MB) at high speeds (300MB/s). So you wouldn't really have to implement the kind of code AQ suggested "everywhere".

[David_Staab]

That depends entirely on what each application's threshold for "slow" is. There exists an entire class of automated test applications that require IPE structures, queue pairs, and "magic patterns" littering the code in order to shave off milliseconds that save the company thousands of dollars a year.

[AristosQueue (NI)]

drjdpowell wrote:

This is so simple an optimization that I would be tempted to label it a bug rather than a lack of optimization.

I'm not going to delve into the details because I don't know them myself, but compiler folks tell me that it is not always an optimization to do this. Something about the way messages in particular are used make it a good pattern for the Send VI but not necessarily universally. I may have more on this topic over the next few months... it's one of those low-priority investigations that I'll keep trying to poke at.

[bspoka]

So I tried using the code that you suggested and it looks like I get about a 15% imporovement in average execution speed of the VI that's responsible for acquiring my large array. See the profiles attached.

[Drew.Rankin]

Don't know if this affects anyone, but I was seeing a similar issue with memory being allocated at around 4KB a minute. I was running the debug actor while developing my application and thought that moving back to the regular actor root might help. It appears that is has, not that the memory allocation has completely been fixed; however, the memory allocation is much slower and looks to be directly tied to new messages being sent or old messages not being disposed of properly. (??)

Not exactly sure; however, I have not observed this happening in LabVIEW directly, but it is definitely noticeable when I create an executable.

One thing to note, is that I am not sending large arrays around the application like bspoka so the actual data should not be an issue; however, I have many actors running - around 40 or 50 - concurrently. Haven't really seen the actors that talk to NI hardware giving me issues, but the actors that communicate with serial hardware are definitely acting (no pun intended) strangely. Once the serial actors are spun up and communicating to their hardware, they seem to stay stable as far as memory allocation goes, but I am not sure how to look into the memory space of a compiled application. Is there something similar to the tool that bspoka used above that works with the LV runtime and an exe?

[AristosQueue (NI)]

bspoka: That's in line with my theoretical estimates. Now to talk with the compiler folks about whether they can do something or whether I need to change the AF templates. Thanks.

Drew: Almost every time I've had someone show me code that has this problem, the "leak" has been refnums that they are opening and not closing. Double check that all of your "Obtain Queue" and similar functions have a matching "Close Reference" call. I am fairly certain that the Desktop Execution Trace Toolkit that bspoka used can attach to the LV runtime engine. ... double check the documentation to be sure, but that's what I recall hearing.