Community Nugget 4/08/2007 Action Engines

[DFGray]

Here is an example of an AE with "memory management".  I threw it together with minimal testing, but it should work as a simple example.

Message Edited by DFGray on 04-13-2007 08:39 AM

[crelf]

Nice job Ben!  Certainly very thorough 🙂

---

@Ben wrote:

*LabVIEW Programming Techniques" produced by Viewpoint Systems Version 2.2 August, 2000 page 67. I believe this book was the precursor to the original version of NI’s "Advanced Applications Development Course"

---

Actually, the Advanced Application Development Course was originally written and taught by VI Engineering, Inc, and formed part of our VISTA Program.  The course was later sold to NI.

[Ben]

Chris wrote;

"

Actually, the Advanced Application Development Course was originally written and taught by VI Engineering, Inc, and formed part of our VISTA Program.  The course was later sold to NI.

"

 I stand corrected!

Thank you for setting the record straight. I knew one of those books I read was the basis of the advanced course.

Ben

Message Edited by Ben on 04-14-2007 01:17 PM

[rolfk]

---

@Matthew Williams wrote:
To follow up on DFGray's comments, I usually keep a pointer (in the AE) to the next available location in the AE array.
When the pointer = array size, time to go get more array elements.  If you allocate in 100 entry chunks your memory
manager overhead is decreased by ~99%, with modest over-allocation.  Works very well for typical AE array sizes we
work with, hundreds to low tens-of-thousands elements.

Matt

---

My approach for such adaptive memory management is usually to start with a certain value (100 is quite a good one) and then
when I run out of memory I always double the array size. This has IMO provided about the best performance without sacrificing to much memory.

Rolf Kalbermatter

[Matthew_Williams]

Thanks Rolf.  There is definitely a trade-off between over allocation and speed, and
we have used both approaches.  Doubling is probably the lowest overhead approach
when you can't preallocate.  We have applications, however, where the potential
over allocation worries me.  The first n doubles are never a problem; it is always that
n+1 double that crashes the memory manager (or makes it go virtual) and leaves
you with a 49% unused array.  Both techniques work, and, fortunately, each application
is unique so we all get to remain employed 🙂

Thanks.

Matt

[crelf]

---

@Ben wrote:

"Actually, the Advanced Application Development Course was originally written and taught by VI Engineering, Inc, and formed part of our VISTA Program.  The course was later sold to NI. "

I stand corrected!   Thank you for setting the record straight. I knew one of those books I read was the basis of the advanced course.

---

No worries Ben - we're actually quite proud of the old course as it departed from some of the traditional topics covered by NI's internal courses and branched out into some real advanced concepts.  Apparently (I've been out of the training side of things for a while, so my Certified Professional Instructor certificate is going a little yellow on my wall 🙂 ) the course has changed quite a lot since we handed it over.  I'm looking forward to helping shape future LabVIEW training, both internally and externally.

[Jim_Kring]

Great article, Ben.  Kudos and thanks! 🙂

-Jim

[Ben]

You are very welcome Jim!

Thanks you to all of the readers and contributors of this Nugget.

It was fun and I learned some stuff along the way.

Ben

[Ray.R]

Very good post Ben.

Sorry to take so long to congratulate you..  I was digesting all this concept.  Very nice indeed!

RayR

[tst]

Here's a link to another action engine example I posted a while back and which demonstrates using them to handle UI updates.