LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Open VI reference is very slow if VI is not already loaded in memory

Solved!
Go to solution

I have several .vit in my project to be opened asynchronously. I noticed that in development environment, it took significantly longer time to open a reference when those .vit front panels were not already loaded. For example, it took 7s for node Open VI reference to finish vs 900ms if the vit front panel was already open.

 

Here is how I benchmark the time it took for Open VI Ref to process:

Clipboard_20160821.jpg

 

Reading the forum, there were several reported topics but they were quite old. I am using Labview 2015 32 bit. I haven't technically benchmark the time in executable environment but I recall it couldn't be no where near 7s to load a vit of size 500KB. 

 

Tests for several different .vit yielded similar results, the time to load depended on the complexity and size of the vits. But complexity and code size shouldn't matter, should it ? I was just opening a ref, haven't got to the VI Run node yet. What could cause this issue and how do I fix it ?

 

By the way, during this 'load time' the entire LV project environment seemed to hang and went into spinning wheel mode. Other running VI also paused and only resumed the loading finished.

0 Kudos
Message 1 of 12
(5,611 Views)

@zigbee1 wrote:

I have several .vit in my project to be opened asynchronously. I noticed that in development environment, it took significantly longer time to open a reference when those .vit front panels were not already loaded. For example, it took 7s for node Open VI reference to finish vs 900ms if the vit front panel was already open.


When you open a reference to a VI, that VI has to be in memory.  If it isn't, then it must be loaded.  So it makes perfect sense that it should take longer to load a VI that was not already open.  But your times seem extreme.  How large are these VIs?  And yes, larger VIs will take longer to load.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 12
(5,599 Views)

The vit that took 7s to load was 500Kb. Smaller vit loaded faster but still they can't possibly take so much time to load.

0 Kudos
Message 3 of 12
(5,586 Views)
Solution
Accepted by topic author zigbee1

Was the VI being loaded saved in an older version of LabVIEW so that the load time is increased because it needs to recompile it for the version of LabVIEW you are now opening it in?

0 Kudos
Message 4 of 12
(5,584 Views)

Good point but nope, source version is 15, it is what I have in development environment.

0 Kudos
Message 5 of 12
(5,576 Views)

Using Static VI References (instead of VITs) makes starting asynchronous VIs essentially immediate.  Another virtue of Static VI References is that the same code works in Development and Executable versions.

 

Bob Schor

Message 6 of 12
(5,573 Views)

Open VI reference function has options input. For opening original template VI, we need to select option 0*02. If you do not select this option flag, LabVIEW opens a new instance of the template VI. Edits made to an instance do not affect the original .vit file. This option flag has no effect on non-template files.

Maybe this has some effect on timing.

0 Kudos
Message 7 of 12
(5,539 Views)

Do you have any xcontrols in the vi?

0 Kudos
Message 8 of 12
(5,532 Views)

Hello, I don't have any Xcontrols in the template. And I have always had these template to spawn clones (suffix numeric to template vi's name). That way i can strack how many instances were alive. I tried several options including 0x80,...etc but observed no difference. I can confirm there was no lag when running the executable.

0 Kudos
Message 9 of 12
(5,503 Views)

Just for fun, try saving the VIT as a VI.  It sticks in the back of my mind that VITs take longer to load for some reason.  I do not remember any details.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 10 of 12
(5,486 Views)