Ideas for speeding up dynamic launching

[John Lokanis]

I am looking for ideas or best practices for speeding up the launching of VIs in a test system.

Currently this is how I do it:

All my test VIs are reentrant.

When a test is called, I first check to see if the VI is already in memory. If not, I pass the path to a DAEMON that opens and holds onto a reference to the VI so it stays in memory. I use option 8 and I do not run this reference. It is there just to cache the VI in RAM.

Then, I open a reference (using option 8) to the VI to run the test. This creates another clone of the VI in memory and then runs the test. After the test is done, the results are returned and the VI stops. I then close the reference to this clone.

I have many parallel loops calling these same VIs so there can be many clones of the same VI starting, running and exiting at the same time.

What I am noticing is when I start to reach ~25 of these loops running, the app slows down considerably. I think this is because each clone needs to allocate memory to run and then free it when it stops and is released. Since each loop is calling the same set of VIs over and over, there is a lot of this going on.

What I am looking for is ideas on how to run this more efficiently. One thought is to use VITs instead of templates and then reuse the spawned instances of the templates within each loop. The spawned VI would stay in memory and just be started and stopped as needed. This might reduce memory allocation.

Another idea might be to still use reentrant VIs but keep hold of the reference to the clone within each loop and reuse it instead of freeing it and creating a new clone with each call in the loop.

The key thing is each loop needs to own its own copy of each test VI so no loop can be blocked by another.

Any ideas, no matter how crazy would be appreciated!

thanks,

-John

[MikaelH]

What Reentrant settings are you using for the VI?

Also try to remove the Allow debugging.

//Mikael

[John Lokanis]

QUOTE (MikaelH @ Nov 5 2008, 09:21 PM)

What Reentrant settings are you using for the VI?

http://lavag.org/old_files/monthly_11_2008/post-941-1225948778.png' target="_blank">

Also try to remove the Allow debugging.

//Mikael

I am using Preallocate for all reentrant VIs. I tried to use the shared clone feature but discovered a bug where the garbage collection routine seems to invalidate references in some clones still in use when other leave memory. This only happens for me when running in the RTE under 8.5 and when the VIs are called dynamically. I have reported this bug to NI but it is very hard to repro.

I will modify the build script to set all VIs to no debugging and give that a try.

[Neville D]

QUOTE (jlokanis @ Nov 6 2008, 02:13 PM)

I will modify the build script to set all VIs to no debugging and give that a try.

I thought when building an exe stuff like remove diagrams/front panels, debugging etc was already taken care off, no?

I think in the build you have to explicitly enable "debugging executable" mode..

N.

[John Lokanis]

QUOTE (Neville D @ Nov 7 2008, 09:15 AM)

I thought when building an exe stuff like remove diagrams/front panels, debugging etc was already taken care off, no?

Nope. You need to explicitly set this in the build script. You can to this on a folder by folder basis or a VI by VI basis (you modify the VI Properties when building). Unfortunatly, you cnanot do this on the whole project at once.

FWIW, changing this reduced my EXE from 3.8MB to 3.2MB but appears to have had no effect on speed.

-John

BTW: I forgot to mention that after I cache the VI in memory, the following opens use the VI name as a string when opening a referece, which should be faster. My concern is how LabVIEW handels the creation and cleanup of reentrant clones of the VI and it's sub-vis and how much overhead is incurred in this process.