Asynchronous Call takes long time for VIT files

[Francois Normandin]

I was updating a reuse template of mine for asynchronously calling itself to simulate as an example for inter-process communication tests.

It took me some time to find out what was causing the first level to be slow. It seems the culprit is the reference to the VIT file.

The stripped-down template below (LV2011) launches a clone of itself everytime we press the "Launch Async" button.

Async Launch of VIT.vit

You'll notice the time required to open the reference is immensely larger when you click on the first copy than on any others.

And it scales rapidly with VI size. My full template is 184kB and takes 3.3s to load the reference. This one is 20kB and opens up in ~200ms.

Simply changing the extension to .VI solved the problem.

Is there anything I'm not doing correctly? Should this be considered a bug or a feature?

Edit: Added a small video on Jing... http://screencast.com/t/aN29fYxJw3A6

[ShaunR]

They are all 1ms for me (including the first one).

[Francois Normandin]

Thanks Shaun. Perhaps I should restart LabVIEW.

Edit: I'm on LV2011 (no SP1) 32-bit.

[crossrulz]

I'm getting 182 to 184ms for each launch. (XP, 32-bit, 2011 SP1)

[ShaunR]

Yeah. Sorry. Not much for you to go on

All 1ms (LV2011x32SP1 andr 2011x64SP1 Win7 x64 and Win8 x64)

I'm getting 182 to 184ms for each launch. (XP, 32-bit, 2011 SP1)

About time you put in a capital req for a new PC

Edited April 4, 2012 by ShaunR

[Francois Normandin]

About time you put in a capital req for a new PC

He's still faster than on mine.

[drjdpowell]

Perhaps with VITs, the block diagram as to be traversed to see if changes need to be made? I notice that when using a VIT, the block diagram is changed slightly, by having the reference updated to point to the new VI created rather than the original VIT. Checking the block diagram could take considerable time (215 ms on my XP-on-virtual-machine system). Making a clone, on the other hand, requires only a new data space.

[ShaunR]

He's still faster than on mine.

OK.

I get 1ms accross the board (even 2011f2). This is just loading it straght up and running. However. Add the file to a project, dbl click and run-> 256 ms.

[Francois Normandin]

OK.

I get 1ms accross the board (even 2011f2). This is just loading it straght up and running. However. Add the file to a project, dbl click and run-> 256 ms.

Yep, I confirm this too on my machine.

Well, this is mostly for understanding how it works under the hood, because a VIT file is not intended to run as a main program, unless in Development environment.

It's gonna end up in a palette with "Drop VI Content"...

I'll send a support ticket just to know if that's a bug or expected results like suggested by James.

About time you put in a capital req for a new PC

Looks like Crossrulz has the best computer after all.

[asbo]

My very first Launch was ~25ms and the rest (even at the top-level, weird) were 1-2ms outside of a project. Once it's in a project, I get 300-350ms at top-level, and 0-2ms elsewhere. Thinkpad T510 with Win7 x64 in LV2011 32-bit.

[ShaunR]

Looks like Crossrulz has the best computer after all.

Depends whether it was run from within a project or not

Edited April 5, 2012 by ShaunR

[Aristos Queue]

Why are you still using VITs for dynamic instantiation of VIs? Of course its slow! Instantiating a new VI from VIT creates a wholly independent copy of *the entire VI*. Contrast this with creating a new clone of a reentrant VI, where we only clone the dataspace and the front panel if and only if its open. We never clone the block diagram, just draw it in two separate windows.

Replicating VITs was a practice that should have largely stopped in LV 8.0 unless you are scripting new VIs as part of an actual "create me a brand new VI in the editor" tool. There are some edge cases when you're actually scripting new controls, but most UIs don't use that approach because it only works in the full dev environment, not the runtime environment. So for UI work, stick with reentrant clones.

This is why going from .VIT to .VI has an impact -- instead of copying the VIT to create a new VI, you're just cloning the reentrant VI.

[mje]

I've been following this thread wondering what it is about VITs that would make them desirable to use over reentrancy, but didn't want to derail it. I think AQ just answered question: nothing.

[Francois Normandin]

Honestly, this is the first time I use a VIT file for instantiating VIs. (Probably first time I save a VIT file altogether!)

I naively thought I'd put my "template" in the Getting Started Window where I could call it with other templates... Isn't that what templates are all about?

Of course I'll put this VI has a "Drop VI Content" icon in the palette and will never use the GSW template... but that's not the point.

I had a perfectly working VI and when I saved it to a VIT file, I tested it one more time before packaging it and noticed it was slow on first generation calls. And by slow, I mean 3300ms! (200ms for the stripped down VI I posted above).

Copying an entire 184kb VI in memory should not take 3.3 seconds. If there is something potentially going wrong under the hood, I think it's my responsability to point it out for further investigation by the experts. Then again, it might be perfectly normal. I would not even have noticed a 200ms delay in launching the async VIs.

And frankly, I never heard of anything like "don't use VIT files anymore, they're useless". If it is an official message, then it hasn't been heard.

[asbo]

I suspect that there's a recompile in there too, so account for that.

[Francois Normandin]

Definitely plausible.

I think it's clear it's a situation to avoid, but just for the sake of understanding, why would there be a difference between in-project and out-of-project VIT?