Suggestion: open a ref to Actor.vi only on first call

[AristosQueue (NI)]

Darn it. Now you've vindicated my paranoia. You know that just increases it for next time.

[drjdpowell]

It's not parinoia if they really are out to get you.

[drjdpowell]

Just a note: but I see that the "Time-Delayed Send Message" VI in LabVIEW 2013 uses the async call by reference in the way the "Launch Actor" used to.  Changing it to the new way will eliminate the potential for being blocked by root loop (and would also significantly reduce overhead).

[KuGr]

So a (another) snowy day in central New Jersey and I had some time to look into this.  I do not use the Time-Delayed Send Message VI directly, but I do have a class that encapsulates the concept and pretty much uses the guts of this VI for its launcher.  I unfortunately have no metrics to compare it to except that I had a developer that continuously launched one of these and it was a noticeable hit as seen by the time stamp of the in my log files.  I ended up augmenting the delay by making the original terminal the initial delay (can be -1 for waiting forever) and adding another terminal for subsequent delay (can be -1 and only initial delay happens, then waits to be rearmed).  A ResetDelay method sets new initial and subsequent delays.  So the Time-Delayed Core loop sticks around until it is destroyed by launcher - just like an Actor and one of it's nested Actors.

All I really can say is the concept works as expected and thanks for the idea to try it out.

[AristosQueue (NI)]

drjdpowell: Could you please check my surgery on this subVI? I believe I have got everything connected up correctly.

(VI saved in LV 2013)

[KuGr]

AQ, For what its worth, it looks good to me.  A simple test using the default AF template in 2013 worked.  Again still no metrics to compare against.

[AristosQueue (NI)]

Cool. Powell is right about the issue -- it's worth fixing even if it isn't your core issue. I'll try to slip it into the waning moments of 2014.

[drjdpowell]

The VI look's fine to me.

The change should significantly reduce the overhead of launching the VI.  The current method creates a new clone pool each time.  Below is a test of a similar "Delayed Send.vi" that I use in my Messenging framework, which uses the newer method of holding a reference to a single clone pool.  The Test launches the "Delayed Send" VI ten times, and then repeats the set of ten twice (to see the overhead of reusing clones).  I ran the VI three times, with delays of 40, 20, and 10 ms, which you can see in the chart:

The launch time of the first call is about 25ms, which is the overhead of creating the clone pool.  If I use a more accurate timer, I can measure the average creation time of a new clone for the pool, about 0.5 ms, and the average time to reuse an already existing clone, abut 0.1ms.  So I expect a very significant performance improvement (after the first call, of course).  The 25ms delay will also throw off your delay time (my code records the start time before the ACBR node, in order to try and correct for launch time, though this fails on the first call when the delay is less than 25 ms).

Added at a later date: I redid the test with LabVIEW 2013 (above was 2011); the initial time to create the initial clone pool is now down to 3ms, in place of 25ms.  Times for additional clones, or reuse of clones, are about the same as before.

Message was edited by: drjdpowell