Run VI invoke node slows down the execution speed

[PrasannaSSRK]

Hello LabVIEW users,

I have a VI which calls around 12 VIs using Run VI invoke node. I have an array of all the VIs references and used a for loop and auto-indexed it to give to the Run VI invoke node. When I checked the execution speed of that for loop, it took around 4 seconds, which is undesirable for my project. Is this the natural way how Run VI node behaves or am I doing it wrong here??

[Yamaeda]

Assuming your parallell loops are set to 4 instances you'll run 4 at a time in 3 sets, is that what takes time?

/Y

[PrasannaSSRK]

Initially, I had the for loop without Iteration Parallelism enabled. It took 4 seconds for completing the execution. Then I enabled parallelism and set to 4 instances of the loop to run at a time. Still, it took 4 seconds to complete. I think the issue is with the node.

[Ben]

Is it 12 different VIs or a single VI?

If it is the latter they have to be reentrant and opened with the correct switch (X08 ?).

Ben 

[altenbach]

How big are these VIs? Are they already in memory when you try to run them? Are they compiled in the current labVIEW version or are they upconverted every time? Do you really need to close the reference?

[billko]

---

@Ben wrote:

Is it 12 different VIs or a single VI?

If it is the latter they have to be reentrant and opened with the correct switch (X08 ?).

Ben 

---

I've experienced something similar.  I had created a re-entrant VI that would, among other things, wait for a specified time and then do something.  I kept wondering why the expected wait seemed to be some combination of the wait times every time the re-entrant vi was called, until I looked at the inline_wait.vi that someone had given me.  It was not marked re-entrant, so it had to wait for itself each time, and since all these re-entrant VIs were constantly queueing up, they all had to wait for each other to get done.  The wait times depended on how many were in the queue at the moment.  Apparently no one there had written a VI sufficiently parallel enough where the inline_wait.vi could be called at the same time from different places, so no one noticed this fatal flaw..  Yikes.

[tyk007]

Run VI invoke node is one of the VI Server methods that requires exclusive execution in the LabVIEW root loop (a term describing the core LV run-time logic that executes as part of the message loop at the heart of every Windows application). In which case it executes on the single User Interface thread so it can't be executed in parallel by definition.

Normally you can tell which nodes require exclusive access to the root loop - if you look at the context help for the node it normally has the phrase "Must wait until user interface is idle: Yes". All control, VI and Application VI Server properties/methods require the root loop although some nodes can be run cooperatively (those with a "No" in the phrase above) which reduces the impact the User Interface thread (but not to zero).

Jon has a good post about it here: http://www.labviewcraftsmen.com/blog/the-root-loop.

Aristos has also said many interesting things about the root loop over the years; good reads are these: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Run-Method-should-not-run-in-the-user-interface-thread... and http://forums.ni.com/t5/LabVIEW/property-nodes-case-structures-amp-the-UI-thread/td-p/1661366

[PrasannaSSRK]

They are 12 different VIs launched from the main VI using the RunVI invoke node.

[PrasannaSSRK]

They all are of producer consumer architecture doing different tasks like logging and measurement stuff. They all are of same LV Version.  I even tried removing the close reference node. Still no change in execution time.

[Ben]

If you are just using that For loop to launch VIs that run in the background, starting up a dozen VIs in 4 seconds may not be bad.

What are you expecting?

If you offer more info someone maybe able to offer some alternatives.

Ben