Long executable load times due to "time critical" priority setting

[jqu]

Hi all,

after a seemingly endless search I found out about the cause of extremely long load times of an executable build with labview 2014 SP1. I'm sharing these findings here in case somebody experiences similar issues and in the slight hope to acquire information on the origin of my observations.

The background: The load time of a large application (~3500 VIs) began to increase steadily at some point in the past. It started at around 5 seconds, went to 15, 23, 45 seconds as further features were added, and recently ended up at almost 4 minutes, which was finally unbearable. All my attempts to clean up cross-dependencies among the components of this application did not yield any improvement. I noticed however, that the order in which the components were loaded (we use "tree VIs" to statically bundle dynamic dependencies) does have a significant influence on the total load time.

To cut things short, here is the "solution" for this problem: There were several VIs (~20) set to "time critical" priority. Everything that was loaded after a "time critical" VI was in memory took extremely long (several seconds as compared to fractions of a second). So I reduced all these priorities to "high", which was already sufficient to reduce the executable load time from over 3 minutes and 40 seconds to only 6 seconds! Needless to say that as of now I did not observe any negative effect due to the reduction of the priorities.

This said, let me add that I have no clue, why "time critical" VIs have this disastrous influence on loading time. May somebody with insight into the load process could be so kind to shed some light on this issue?

Cheers,

jan

[Norbert_B]

Jan,

does your application use "run when loaded" configuration for VIs?

Do you use LLBs, PPLs (lvlibp), classes and other forms of libraries?

Norbert

[jqu]

Hi Norbert,

there are 7 VIs that use "run when opend" in the execution properties. I do not see any "run when loaded" option, which may be a decisive difference here. I would think that a "run when opened" VI does run automatically when the front panel is opened, but it should not run when it is loaded into memory, correct?

We do not use LLBs or packed libraries, but lvclasses and "normal" libraries. In fact, ordinary lvlibs are used quite a lot. We have our own OOP framework, which is similar to the actor framework. Each class is organized in its own lvlib. Additionally, there are a few lvclass objects scattered around in some old legacy code...

Greetings,

jan

[Norbert_B]

Indeed i was mixing that up and talking about "run when opened" option. Sorry for the confusion.

Are these classes cross-linked?

Also please elaborate if you are talking about loading the project (lvproj with depending vi, llb, lvlib, lvclass, ... files) or if you are talking about an executable (EXE) file.

Norbert

[jqu]

No Problem.

I am strictly talking about an executable. First, a "splash screen" is run as "startup VI", which displays a progress bar and opens all other components (Tree VIs) via "Open VI reference". It is the latter part that takes awfully long if individual VIs are set to "time critical".

I'm not quite sure, what cross-linked actually means in this context. If you refere to bidirectional static dependencies between libraries, then yes. At first I suspected these dependencies to be the problem and started to disentangle them. But I had to realize that this had almost no effect at all on the load time and therefore I stopped this tedious work.

jan