What influence how long it takes to launch an actor?

[QueueYueue]

I've got a huge application that is supposed to be able to do a lot of different things (i'll call these things tasks), but each different tasks is completely independent from the other. Basically, it's a one-stop-shop for an entire lab.

 

Each of the different tasks are actors launched from a top level UI and sent a message to insert their actor core into a sub panel. There is a noticeable delay between when the user clicks the button to launch the task, and when the UI actually shows up. We're talking about about 1000ms between when the button is clicked and the UI shows up.

 

I did some profiling and I figured out that my overridden actor cores are responsible for some of this delay (i'm doing some slow code (100ms) before I execute the call to parent in the actor core).

 

Launch actor however is responsible for most of the delay. I took a look at the two worst ones. Their launch actors were taking on average 500 ms and 700 ms respectively (meaning actor 1 always took about 500 ms, and actor 2 always took 700 ms). That doesn't make sense to me. Why do different actors take different amount of times to boot?

 

I took a look into what launch actor is doing, and i found one thing that could change how long each type actor took to boot: Pre-launch init. If i had slow code in pre-launch init, then it would slow down launch actor. However, in my case, both actors had identical pre-launch inits. Meaning as far as I could tell, they should have similar launch actor times.

 

So my question is: What affects how long it takes to launch actors? Where should I look next? I won't be able to post code, and i've been unsuccessful in re-creating in a smaller project.

 

Edit: Oh god the title. I accidentally a letter

Edited August 23, 2013 by QueueYueue

[Tim_S]

I'm not too familiar with the Actor Framework yet, but are your actors/tasks in memory or do they need to be loaded when the user clicks the button?

[K-node]

Non reentrant VIs called from pre launch init will cause the others to wait. Just a thought.

 

Update:

If you look ahead at posts 14 and 15 you will see that though Pre Launch Init is reentrant, it will never act like a reentrant vi during the launching of an actor.  So making any Pre Launch Init supporting VIs reentrant will not improve the launch performance.

Edited August 28, 2013 by kugr

[todd]

... i'm doing some slow code (100ms) before I execute the call to parent in the actor core ...

Are you sending the nested actor's VI ref to the parent for insertion into the subpanel? If so, I suppose the caller's insert method doesn't do anything else? Even so, is there a chance the caller is busy with other methods and doesn't get to the Insert in a timely fashion?

 

If i had slow code in pre-launch init, then it would slow down launch actor. However, in my case, both actors had identical pre-launch inits.

 

I tried putting config file reads in pre-launch init, for a while - then I stopped doing that. My pre-launch inits are very lightweight, now.

 

Lately, I send the subpanel ref to the actor in its class data before calling launch. If the nested actor sees that it's a valid subpanel, it inserts itself. Otherwise, it opens its FP - or remains headless. A subpanel ref can be sent in later, if needed.

[jcarmody]

... I accidentally a letter

 

You accidentally a word, too!

[todd]

You accidentally a word, too!

 

I bet that was purpose.

[Aristos Queue]

 Meaning as far as I could tell, they should have similar launch actor times.

Were you launching them in parallel? Pre-launch Init.vi is called under Launch Actor which is deliberately not reentrant. Only one VI launches at a time, so if you try to call Launch Actor in parallel, you will get a delay as they serialize launches.

[K-node]

> Pre-launch Init.vi is called under Launch Actor which is deliberately not reentrant.

 

Really?  Crap!  Somehow mine got changed. 

 

I am sure this was discussed somewhere, but what is the best way to protect Actor Framework.lvlib and its files from getting altered?  Do I write protect the files in that folder?

[todd]

I vote for the lvclass, ctl, lvlib and vi files to be "locked-no password" during the Post-Install Custom Action in VIPM (or VIPM pro has a checkbox that does this).

[QueueYueue]

I threw some more timing into everything, and here's what I found.

 

It's the close reference after the call by reference that is taking 90% of the execution time.

 

The situation we have is sort of like tabs with sub panels. So when the first "tab" is launched, everything goes quickly (under 200 ms), then when you start switching tabs, every other close ref takes longer. The close ref time does not continue to grow, it just shoot up the the 1 second mark and stays there.

 

So now i guess my question is: what affects how long it takes to close the reference?

[drjdpowell]

Which version of “Launch Actor” are you using?  The newer version shouldn’t be closing the reference to “Actor.vi” at all (link).

[K-node]

... Pre-launch Init.vi is called under Launch Actor which is deliberately not reentrant. Only one VI launches at a time, so if you try to call Launch Actor in parallel, you will get a delay as they serialize launches.

 

I misunderstood the statement.  Launch Actor is not reentrant, Pre-launch Init.vi is reenttrant.  Phew, I thought my lvlib got whacked somehow.

[QueueYueue]

Which version of “Launch Actor” are you using?  The newer version shouldn’t be closing the reference to “Actor.vi” at all (link).

This was the problem. I didn't realize there was an update released.

 

Thanks a lot.

[Aristos Queue]

Kugr: I have no idea why we made pre-launch init.vi be reentrant. No point since it is only called from a non-reentrant caller. Unfortunately, changing that would be a breaking change needing mutation.

[K-node]

Kugr: I have no idea why we made pre-launch init.vi be reentrant. No point since it is only called from a non-reentrant caller. Unfortunately, changing that would be a breaking change needing mutation.

 

I just want to make sure I understand this.

 

Pre Launch Init.vi  is actually called from Actor.vi which is reentrant and launched by the ACBR node in Launch Actor which is non-reentrant.  However, at runtime it is operates like a non-reentrant VI since another Actor.vi/ACBR will not happen until the 'active' Pre Launch Init completes and the new Actor's Enqueuer is sent back to Launch Actor.

 

So unless some developer calls Pre Launch Init from somewhere else in their code, albeit a bad practice, there will only be one shared clone.

 

If that is the case, I take back my statement in Post #3.

[Aristos Queue]

I don't remember how we got it to work. I do know that you can't get two actors launching simultaneously. Regardless of the mechanism, there's no reason for Pre-Launch Init.vi to be reentrant.