Dynamic loading of an external VI - LV2020

[cowen71]

Hi All,

Maybe someone has experience of this.

We have an application that is compiled into and EXE and a number of reentrant process steps that are external VI's.

To improve loading speed of the external steps, the first time a step is called, we store a reference to the step that is never executed. In this way, all dependencies of the step are held in memory (we have a library of functions that are also outside of the EXE).

Each call to the step then opens a new reference to the step but we find this is much faster. For example, the first call to the step may take 200mS, subsequent calls take maybe 30mS. This has worked very well with LV 2013 and LV 2017.

We have recently switched to LV2020 and whilst the mechanism to store the reference has been proved to be functioning well, it is actually not helping with the loading time of the steps. In fact we are seeing that opening the references is now taking 500mS or more.

I welcome any ideas or suggestions of how to solve this.

[MaSta]

It is really necessary to keep the external code as VI? May we know why?

By the way, you seem to fight the symptoms, not the cause.

[paul_cardinale]

When I do stuff like this, I use the already-opened-reference instead of opening a new reference.

[cowen71]

HI,

Thank you for the response.

I am absolutely trying to find the cause. 🙂 Maybe my wording suggest otherwise.

We have a standard software solution that provides many functionalities covered by many different steps. In this case to include all steps inside the EXE would be impractical and result in an extremely large EXE that is significantly less flexible. But moving the steps into the EXE really does address the symptom and completely disregards the cause. Generally speaking I do not want to re-engineer a solution because we have updated our LabVIEW version.

[cowen71]

In this case we cannot us the actual stored reference. All of the steps are reentrant and we sometimes need to run them in parallel. Of course they are called asynchronously and so a new reference is needed in each case. I know we can open a reference for multiple calls but this creates a different problem with regard to collecting results from specific VI instances.

The main point for me is that I can imagine many ways that may help (perhaps not??). Ultimately though, we have a solution that has been running well for about 10 years and now, with the latest LV version, we see performance issues.

My hope was that there was just a new option or method that provided improved loading functionality and that the old functionality was just outdated. My expectation now is that the newer LV version just performs worse in this area. The next step I guess it to try the very latest LV versions. But this introduces a new set of problems.

In any case, thank you for your feedback.

[cowen71]

A small update.

As written, with LV 2017 compiled app, the deynamic VI starts in about 200mS the first execution and in under 10mS the second run.

Compiling the app with LV2020, the VI starts in maybe 800mS the first execution and not much faster the second run.

I have just launched the LV2020 app with the option 'Run as Administrator' in Windows, The LV2020 EXE is now performing comparable to the 2017 version. I now just need to figure out why!