Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Application load/launch time issue

Hi all,

I have an application built using AF that is taking much longer to load and launch than the version it is replacing.  Like go get a coffee and talk about sports for a minute long.  The application launcher is copied from the AF example, calling the Load App method in a Controller class, which then launches whatever actors the particular implementation is using.  Subactors are launched using a factory within the Controller.  The inheritance tree is three or four deep for some of the subactors.

Benchmarks on all the actual code show that it executes in a reasonable amount of time, but every time I have to launch a new actor there is a huge delay.  I'm at a loss for what the holdup is.  Where should I start looking to solve this problem?

Thanks

CLAD
0 Kudos
Message 1 of 41
(12,476 Views)

Use the debug-only Boolean input on Launch Actor to open the panel. Is your delay before or after the panel opens? If before, it is code in your Pre-Launch Init.vi. If after, it is in your Actor Core.vi. Remember that Pre-Launch Init won't let two Actors run at the same time, so one slow actor there will keep the others from launching.

0 Kudos
Message 2 of 41
(4,692 Views)

Thanks AQ.  The delay is before the panel opens, however there is no code at all in my Pre-Launch Init VIs for any of the classes.  Infact, none of them override that VI at all.  I do have an Initialize.vi that I call before launching the actor, but that code all takes a reasonable amount of time to execute (and posts notifiers to the FP of the launch screen so I know it didn't hang.)  The longest delay comes after I hit the Run button on the launcher.  It will sit there for a few minutes before I see the first notification that my Initialize VI has done anything.  Could this be an issue with ancestors not being loaded into memory until I hit the run button?  I remember seeing an example where the author had dropped class constants of all the ancestors into the child class' Load Application block diagram with the note, "These are here to make sure all ancestors are loaded into memory."

CLAD
0 Kudos
Message 3 of 41
(4,692 Views)

It sounds like it might be an IDE issue not a code issue.  I've seen a pause on hitting run when using a lot of dynamic launching.  Have you tried the shift-ctrl->run trick or deleting the object data cache?  Not sure if these will help. 

Just some suggestions.

0 Kudos
Message 4 of 41
(4,692 Views)

My app has done the same thing for the last year when I run from the IDE.  Takes about 20 seconds from the time I hit run until I see activity.  And I'm nearly sure that it's not any code I'm doing at launch, because the top level doesn't hardly do anything until it gets user actions ... all it does is launch other things on demand.

I'll bet you can't drag the window around by the title bar like normal while it's 'paused', right?  That thing is locked where it's at on the screen until it's ready to run, in fact all of LV is locked to UI actions.

0 Kudos
Message 5 of 41
(4,692 Views)

Oh... a delay after hitting the Run arrow itself. Gotcha.

Does it happen twice? I.e., if you run once, stop, and then run again without making edits, does it happen the second time?

If it doesn't happen the second time, that's the compiler compiling your VIs.

If it does happen the second time, it is VI reservation, which is when all the constant folding code and static VI ref initialization occurs. Look for code that is largely constant-foldable and try replacing the code with a hard-coded constant value.

0 Kudos
Message 6 of 41
(4,692 Views)

Note: when you originally said launch was slow, I thought you meant the Launch Actor subVI was slow to execute when called. The problem you're actually talking about is a delay before ANY node executes. I hate to be pedantic, but if you describe the problem wrong, I'll send you down some very twisted rabbit holes. 🙂

Message 7 of 41
(4,692 Views)

Ben:  That's exactly what happens.

AQ:  I kinda like the rabbit holes...I've learned a lot that way!  I have one application built on this platform that doesn't show the delay the second time and one that does.  The application that is slow on the second launch probably does have a lot of constant-foldable code, but it also has a deeper inheritance tree.  When I launch an actor from within the application (responding to user input), would the same compiler delay happen?  Would the added levels of inheritance increase this delay?  And, most importantly, would this delay disappear after compiling into an exe?

Thanks for the help!

CLAD
0 Kudos
Message 8 of 41
(4,692 Views)

I haven't benchmarked, but in a mental review of reservation algorithm, I can't think of why depth of hierarchy would matter meaningfully. I think the overwhelming factor is total number of VIs and libraries (libraries significantly less than VIs). Having said that... researchers have demonstrated repeatedly that programmers are notoriously bad at guessing the hotspot in non-trivial algorithms, so unless I formally hotspot tested that algorithm, my guess may be waaaaaay wrong. To really answer your questions, you'd need to file a support request and get it escalated to someone in R&D.

One thing I will say -- LV 2014 is supposed to have performance improvements related to that system (I say "supposed" because I saw some Perforce entries but haven't specifically looked into it). I have no idea if they would benefit you, but if you wanted to try, check out

          http://ni.com/beta

0 Kudos
Message 9 of 41
(4,692 Views)

If you had dependency cycles, eg where library A depends on B depends on C depends on A (and of course B depends on A directly as well, would be rude for it not to!), but much worse than that example, could that also cause this?  It would seem that LV would have to traverse that triangle potentially many times to really figure out everything that can affect each VI, or what it would affect itself.

Whatever it is that's happening, it happens before LV gives you an hourglass cursor, and it seems to take all of a CPU core until it's finished.  Exe's of the same app take about 5 seconds to start, but that's no different from any large app I've seen.  It seems like whatever things it has to figure out each time during an IDE run are resolved and set in stone when the exe is built.

We have other apps much larger than this one in same LV version (2012), but that aren't OO or use libraries, and those larger apps do not exhibit this at all ... and they definitely use constant folding liberally.  Granted they DO take a little while to start up, but with the normal hourglass while it spools up and having the ability to move windows around.

0 Kudos
Message 10 of 41
(4,692 Views)