Application load/launch time issue

[AristosQueue (NI)]

Ben: Nope. The reservation pass says, "Oh, that's already reserved... that means its dependencies are already reserved, so I'll skip it." It doesn't walk over cycles multiple times.

[Fire]

Hello

I am observing the delay (about one minute!) after hitting the Run-Button, too. It occures every time in my ongoing AF Project.

Once is started everything is as fast as usual.

The AF-Project-Template and other AF based aplication are starting almost instantanously.

The most obvious difference is the amount and structure of class attribute data. Some actor classes have many clusters, arrays and cluster of arrays in their attribute. Also modifying such class attribute data causes very long delays.

Maybe this is a hint to solve the problem.

Best Regards Holger

[AristosQueue (NI)]

Have you tried the LV profiling tools to see where the time is being spent?

[Fire]

Following the results of the profiler. I started the profiler before clicking the run button of the main VI. I stopped the profiler after the FP of the first, and only, actor became visible. This actor, and all other actors that might be started after, are derived from the Monitored Actor.

The sources can be downloaded from the preview-branch of https://github.com/HB-GSI/CSPP.

I started tracing with default settings before clicking the run button of the main VI and got following error message.

I hope the images are readable. I can send the profile data to you via email, if ist is usefull for your analysis.

From my point of view the LV-VI of my app are not producing any unexpected delays. It seems to be the IDE.

Best regards Holger

[AristosQueue (NI)]

I haven't looked deep at the implementation of Monitored Actor -- I know it was written to have minimal impact in the run-time engine. Is it possilbly delay loading files? I hate to pick on Monitored Actor, but it is the one thing that you've mentioned that I don't have in any of my apps, so it's the first thing I'd check. It might very well be the IDE, but let's rule MA out first. Can you remove MA from your hierarchy and try again?

[Fire]

I removed the Monitored Actor from the inheritance hierarchy, saved all, closed and reopend the project as well as the main VI. Checking the dependencies proofed that the Monitored Actor is not loaded.

The time delay before thr run button change to display the Run Mode was still a minute, maybe 5 seconds less.

Starting nested actors from the main actor is as fast as usual, with or without Monitored Actor.

The good news is: When compiled in an executable the application starts much faster, about 20 seconds the first time and 8s the second and subsequent times. That's fine and comparable to other LabVIEW applications.

By the way: In the first sequence frame of my main VI, I am calling some content.vi's. They contain class constants of all actor classes and other simple non active classes to be used within the application. The message classes are not part of the content.vi's, since they are part of the message dispatcher VIs and automatically part of the hierarchy. This makes it easy to build an application since since the application builder can include all classes from the hierarchie automatically. (Avoiding all problems wioth plugin architectures.) Of course this is constant folding code, you mentioned that before as possible reason for delays, but really not complex.

Regards Holger

[AristosQueue (NI)]

If it is just constants on the diagram not wired to anything, there's no actual constant folding work to be done.

In the dev environment, have you tried turning off debugging?

Again... I'm not saying the IDE doesn't have a problem. I am looking for things that might be the cause that you could actually do something about now.

[Fire]

I created a VI-Analyzer task to disable the Allow Debugging flag for all VIs of my project. The AF library, instrument driver libs and others are part of the project. About 850 VI were modified.

Result: no serious improvement on the startup behaviour.

Remark: I also do want want to blame the LabVIEW IDE. I am gratefull for good ideas. The problem seem to be non-trivial. Thanks the original author to trigger this discussion.

Regards Holger

PS. Some of my derived actor classes are wrapping the IVI_DMM, IVI_DCPwr and IVI_Fgen with complete functionality. Some more the basic features of IVI_Scope, IVI_ACPwr, IVI_Counter and IVI_PwrMeter (Initialize, Close, Revision Query etc.) For the first three classes the corresponding anchestor classes were cerated in oder to define the public interface using IVI, but allow to derive other classes implementing that interface by using legacy intrument driver of other vendors. During my tests i am using the niSimulation drivers.

[AristosQueue (NI)]

At this point, I'm out of ideas. It seems likely to be something LV is doing to reserve the VIs for run. If you'd like it hunted down further, please open a support ticket with ni.com/support and see if they can isolate the issue and/or escalate the issue to R&D.

[Fire]

Thanks for your help to this point.

It will take me some time in order to create the minimal configuration that can reproduce this problem with minimal set of classes. Then I will create the support request with link to this discussion.

Maybe this is a good reason to become beta tester for LV 2014? Would your support me, when I apply?

Regards Holger