Jump to content

What influence how long it takes to launch an actor?


Recommended Posts

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 by QueueYueue
Link to comment

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 by kugr
Link to comment
... 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.

Link to comment
 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.

Link to comment

> 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?

Link to comment

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?

Link to comment
... 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.

Link to comment
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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.