Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 
Reply

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

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

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

Message 31 of 38
(812 Views)

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

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

0 Kudos
Message 32 of 38
(812 Views)
Highlighted

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

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).

0 Kudos
Message 33 of 38
(812 Views)

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

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.

0 Kudos
Message 34 of 38
(812 Views)

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

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

(VI saved in LV 2013)

0 Kudos
Message 35 of 38
(812 Views)

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

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.

0 Kudos
Message 36 of 38
(812 Views)

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

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.

0 Kudos
Message 37 of 38
(812 Views)

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

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:

ACBR Clone pool launch times.png

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

0 Kudos
Message 38 of 38
(812 Views)